Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107905
User-Agent: Cyrus-JMAP/3.1.7-612-g13027cc-fmstable-20191203v1
Mime-Version: 1.0
Message-ID: <faf6c3b4-b9a6-470b-96e9-c59934dd5007@www.fastmail.com>
In-Reply-To: <505a71bd-e77f-564b-e5bb-28fcf8697e40@gmail.com>
References: <a68ab6cf-6a26-43c6-9b12-c41366cce01f@www.fastmail.com>
 <4C8A8CB1-1259-439A-B213-D10D098010A6@newclarity.net>
 <505a71bd-e77f-564b-e5bb-28fcf8697e40@gmail.com>
Date: Sun, 08 Dec 2019 11:43:10 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_Inconsistent_class_behavior_and_undocumented(=3F?=
 =?UTF-8?Q?)_BC_change?=
From: larry@garfieldtech.com ("Larry Garfield")

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 tha=
t 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/
>=20
>=20
> I'm not sure either of those links do a good job explaining why=20
> constructors in particular are special.
>=20
> My first thought was "you call them on the class not an instance", but=
=20
> that's also true of static methods, and yet this is an error:
>=20
> class Ancestor {
>  =C2=A0=C2=A0=C2=A0 public static function constructMe(int $a, string =
$b) { }
> }
> class Child extends Ancestor {
>  =C2=A0=C2=A0=C2=A0 public static function constructMe(...$args) {
>  =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return parent::constructMe=
(...$args);
>  =C2=A0=C2=A0=C2=A0 }
> }
>=20
> In PHP, it is actually possible to call a static method based on an=20=

> instance, using the syntax "$foo::somethingStatic()", so it is=20
> theoretically logical to constrain a set of related classes to have=20=

> compatible static methods. But you can also write "new $foo()" to invo=
ke=20
> a constructor based on an instance, so that doesn't explain the=20
> difference either.
>=20
> The best explanation I can think of is more pragmatic than theoretical=
:=20
> it's often useful to have related objects with unrelated constructors,=
=20
> so it's useful for the language not to restrict that. I'd be intereste=
d=20
> to hear if there's a more fundamental reason, though.

I recall constructors being special with interfaces; I didn't consciousl=
y 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 o=
nly works on constructors.  Sad elePHPant...

--Larry Garfield