<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: BUG: Constructors, Interfaces, and Abstracts Don&#8217;t Mix Well</title>
	<atom:link href="http://www.michiknows.com/2007/12/10/bug-constructors-interfaces-and-abstracts-dont-mix-well/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.michiknows.com/2007/12/10/bug-constructors-interfaces-and-abstracts-dont-mix-well/</link>
	<description>Insights on the IT world by Michi Kono</description>
	<lastBuildDate>Wed, 28 Jul 2010 00:04:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Michi</title>
		<link>http://www.michiknows.com/2007/12/10/bug-constructors-interfaces-and-abstracts-dont-mix-well/#comment-14700</link>
		<dc:creator>Michi</dc:creator>
		<pubDate>Wed, 20 Feb 2008 08:59:39 +0000</pubDate>
		<guid isPermaLink="false">http://www.michiknows.com/2007/12/10/bug-constructors-interfaces-and-abstracts-dont-mix-well/#comment-14700</guid>
		<description>This actually has been fixed in PHP 5.25. It was not a feature; it was a bug.

The point of interfaces is to define how you interact with a class -- if a class can have a different constructor despite an interface telling it otherwise, the entire paradigm breaks down, no?

What if I wanted to make an interface for a factory pattern class? In such a case, being able to tell implementers that the constructor MUST be protected makes a lot of sense. Why in the world is taking that a step further and enforcing a certain type of argument not make sense? What if my factory interface was for classes that convert other classes, and thus expect a certain class object as a constructor argument?</description>
		<content:encoded><![CDATA[<p>This actually has been fixed in PHP 5.25. It was not a feature; it was a bug.</p>
<p>The point of interfaces is to define how you interact with a class &#8212; if a class can have a different constructor despite an interface telling it otherwise, the entire paradigm breaks down, no?</p>
<p>What if I wanted to make an interface for a factory pattern class? In such a case, being able to tell implementers that the constructor MUST be protected makes a lot of sense. Why in the world is taking that a step further and enforcing a certain type of argument not make sense? What if my factory interface was for classes that convert other classes, and thus expect a certain class object as a constructor argument?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matthijs Kooijman</title>
		<link>http://www.michiknows.com/2007/12/10/bug-constructors-interfaces-and-abstracts-dont-mix-well/#comment-14699</link>
		<dc:creator>Matthijs Kooijman</dc:creator>
		<pubDate>Tue, 19 Feb 2008 09:14:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.michiknows.com/2007/12/10/bug-constructors-interfaces-and-abstracts-dont-mix-well/#comment-14699</guid>
		<description>It might be me, but it seems this behaviour is really intentional. I&#039;ve never seen another OO language that allows constructors in an interface, let alone enforces implementing classes to have those. An interface is mainly meant to be able to talk to an object that&#039;s already instantiated, even when you don&#039;t really know it&#039;s type (just that it conforms to some interface). Due to the lack of type-safety in PHP, this is a bit confusing (it reduces interfaces mainly to extra checks for the compiler...)

As for the abstract parent class, it&#039;s actually a feature that the constructor arguments of the child class can be different. It&#039;s not uncommon for a parent class to have some constructor argument that will be different depending on the subclass used, not depending on how you call the constructor.</description>
		<content:encoded><![CDATA[<p>It might be me, but it seems this behaviour is really intentional. I&#8217;ve never seen another OO language that allows constructors in an interface, let alone enforces implementing classes to have those. An interface is mainly meant to be able to talk to an object that&#8217;s already instantiated, even when you don&#8217;t really know it&#8217;s type (just that it conforms to some interface). Due to the lack of type-safety in PHP, this is a bit confusing (it reduces interfaces mainly to extra checks for the compiler&#8230;)</p>
<p>As for the abstract parent class, it&#8217;s actually a feature that the constructor arguments of the child class can be different. It&#8217;s not uncommon for a parent class to have some constructor argument that will be different depending on the subclass used, not depending on how you call the constructor.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sam Jones</title>
		<link>http://www.michiknows.com/2007/12/10/bug-constructors-interfaces-and-abstracts-dont-mix-well/#comment-13400</link>
		<dc:creator>Sam Jones</dc:creator>
		<pubDate>Fri, 04 Jan 2008 16:29:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.michiknows.com/2007/12/10/bug-constructors-interfaces-and-abstracts-dont-mix-well/#comment-13400</guid>
		<description>Thanks Michi!</description>
		<content:encoded><![CDATA[<p>Thanks Michi!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
