Re: Inconsistent class behavior and undocumented(?) BC change

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]