On 08/12/2019 05:03, Mike Schinkel wrote:
Hi Larry,
I am not clear on why __construct() is special in this case;
I believe that is the Liskok substitution principle at work, and that fact the
principle does not apply to constructors.
For reference:
-https://softwareengineering.stackexchange.com/a/302477/9114
-https://www.sitepoint.com/constructors-and-the-myth-of-breaking-the-lsp/
I'm not sure either of those links do a good job explaining why
constructors in particular are special.
My first thought was "you call them on the class not an instance", but
that's also true of static methods, and yet this is an error:
class Ancestor {
public static function constructMe(int $a, string $b) { }
}
class Child extends Ancestor {
public static function constructMe(...$args) {
return parent::constructMe(...$args);
}
}
In PHP, it is actually possible to call a static method based on an
instance, using the syntax "$foo::somethingStatic()", so it is
theoretically logical to constrain a set of related classes to have
compatible static methods. But you can also write "new $foo()" to invoke
a constructor based on an instance, so that doesn't explain the
difference either.
The best explanation I can think of is more pragmatic than theoretical:
it's often useful to have related objects with unrelated constructors,
so it's useful for the language not to restrict that. I'd be interested
to hear if there's a more fundamental reason, though.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
