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
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
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 (Pierre)
4) We should meet everyone's existing expectations, Rasmus talks about this:
http://news.php.net/php.internals/25090 (Rasmus)
and this is the general expectations:
http://www.google.com/search?q=constructor+liskov
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) 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
