Hey Ralph, i think your argument on this is wrong. If we go your road:
1. Fact: PHP follows the LSP 2. Fact: The constructor is not part of the type, but a factory method. 3. Conclusion: constructors are not allowed to be part of the interface or abstract classes. Reversing the argument, by introducing an abstract or interfaced constructor you actually make the constructor part of the type, hence LSP applies. Since PHP allows this and follows LSP, this has to be enforced. greetings, Benjamin On Fri, Nov 18, 2011 at 6:40 PM, Ralph Schindler <ra...@ralphschindler.com>wrote: > Hey Pierre, > > My perspective and expectations are framed by all sorts of existing > literature as well as the discussions on this list. It saddens me that you > did not address any of the points I've brought up. And, I simply cannot > tell what basis you have for your interpretation and opinion. It seems more > like you're basing your interpretation on preference alone. > > The facts are this: > > 1) What we know and have been told is that PHP's signature checking is > governed by Liskov Substitution Principle. There are many references to > this in the list. > > I've made my argument based on the LSP. > > http://marc.info/?r=1&w=2&q=b&**l=php-internals&s=lsp<http://marc.info/?r=1&w=2&q=b&l=php-internals&s=lsp> > > 2) "Abstract Constructors" do not exist in any other language, for all > intents and purposes, it's something we've invented: > > http://www.google.com/search?&**q=%22abstract+constructor%22<http://www.google.com/search?&q=%22abstract+constructor%22> > > That's fine, so now the question is, how does this thing we've invented > play in with our current implementation of a class based object model and > how does it meet developer preexisting expectations? > > 3) In places that have no formal expectation and understanding in other > programming languages, we've OFTEN favored *looseness over strictness* > > Even you Pierre, once promoted "looseness" > http://news.php.net/php.**internals/25089<http://news.php.net/php.internals/25089>(Pierre) > > 4) We should meet everyone's existing expectations, Rasmus talks about > this: > > http://news.php.net/php.**internals/25090<http://news.php.net/php.internals/25090>(Rasmus) > > and this is the general expectations: > > http://www.google.com/search?**q=constructor+liskov<http://www.google.com/search?q=constructor+liskov> > > http://stackoverflow.com/**questions/5490824/should-** > constructors-comply-with-the-**liskov-substitution-principle<http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle> > > > <?php >> >> class A { >> function __construct($a, $b) { >> } >> } >> >> class B extends A{ >> function __construct($a) { >> } >> } >> >> >> works. >> >> While the following does not: >> >> Abstract class A { >> abstract function __construct($a, $b); >> } >> >> class B extends A{ >> function __construct($a) { >> } >> } >> > > > Which makes no sense b/c this does work: > > abstract class A { > abstract public function __construct($one, $two, $three); > } > class C extends A { > public function __construct($one, $two, $three) {} > } > class D extends C { > public function __construct($foo) {} > } > > I assume this is b/c only one ->ce_parent is checked for "definition > correctness" or whatever this new feature is we're calling ... but more to > the point, do we really want to recurse every parent definition looking for > an abstract __construct() and checking the signature at runtime? > > > does not and it is per definition correct. Abstract defines the >> signature and ensures that the signature are 100% the same. >> > > Where do you get your foundational basis for this? What rules outside of > the LSP are we looking at to make this determination? > > And, can you honestly say that of the global community of developers, this > is the expected outcome? > > > We had a long discussion about that a couple of months ago. The main >> disagreement was about the interpretation of the definition of >> abstract. Abstract clearly talks about signature matching, as I (and >> quite a lot of other) read it. >> > > According to the RFC > (https://wiki.php.net/rfc/**prototype_checks<https://wiki.php.net/rfc/prototype_checks>) > a consensus was never reached - and more discussion was needed (which as of > the date of the RFC and timestamps in the mailing list, has not happened). > > -ralph > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >