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

On Sun, Dec 8, 2019, at 10:14 AM, Rowan Tommins wrote: > 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. I recall constructors being special with interfaces; I didn't consciously realize that *all* inheritance rules were skipped for them. I suppose in that case it's logical that it is why it is, just disappointing; the double-splat trick I was trying above is really nifty, but I guess it only works on constructors. Sad elePHPant... --Larry Garfield