Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99757
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
Date: Wed, 05 Jul 2017 11:24:39 +0100
User-Agent: K-9 Mail for Android
In-Reply-To: <827b77ce-f2b7-930a-34cb-ce11ebc2d531@php.net>
References: <827b77ce-f2b7-930a-34cb-ce11ebc2d531@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
To: internals@lists.php.net
Message-ID: <679F251C-FFDA-4D9A-A0C2-89AA767A2402@gmail.com>
Subject: Re: [PHP-DEV] OBJECT_OPERATOR vs. DOUBLE_COLON
From: rowan.collins@gmail.com (Rowan Collins)

On 5 July 2017 08:08:48 BST, Sebastian Bergmann <sebastian@php=2Enet> wrote=
:
>Is it intentional that the DOUBLE_COLON operator can be used on a=20
>variable that contains a reference to an object?
>
><?php
>class C
>{
>     public function m()
>     {
>         print '*';
>     }
>}
>
>$c =3D new C;
>$c::m();
>
>Until yesterday I thought that only the OBJECT_OPERATOR (->) can be
>used=20
>on a variable that contains an object=2E https://3v4l=2Eorg/59Xap proved =
me
>
>wrong=2E
>
>As the deprecation / strict standards notices suggest, though, $c::m()=20
>does not invoke the method m() on the object referenced by $c=2E It=20
>invokes the method statically on C (the class of the object referenced=20
>by $c): https://3v4l=2Eorg/19taB
>
>I think that using :: on a variable that contains an object should not=20
>"fall back" to a static access on the object's class=2E Instead the=20
>runtime should error out=2E
>
>What do you think?


Hi Sebastian,

Firstly, I'm not sure where you got the names you've put in ALL_CAPS  from=
, but they're not the official names of the operators anywhere I've seen=2E=
 The double-colon is technically the "Scope Resolution Operator", or intern=
ally T_PAAMAYIM_NEKUDOTAYIM (which does mean double-colon)=2E It's describe=
d in the manual here:  http://php=2Enet/manual/en/language=2Eoop5=2Epaamayi=
m-nekudotayim=2Ephp

I too was slightly surprised when I first learned it could be used against=
 an instance as well as a class name, but there are situations where this i=
s useful=2E For instance, accessing a class constant associated to some obj=
ect when interacting with that object, e=2Eg=2E "$foo->doThing($foo::MODE_X=
)"=2E

If we could only use it on class names, we'd have to use the "::class" ope=
rator to go from one to the other, like "$foo::class::MODE_X"; or perhaps w=
e'd change that operator too and write "$foo->class::MODE_X"=2E That's not =
awful, I suppose, but it doesn't feel like a big gain=2E

We'd also need to consider the consistency of "parent::", which resolves t=
he scope but *doesn't* force a static access, because you need to be able t=
o call an inherited non-static member=2E

Like most established languages and frameworks, we don't have the luxury o=
f going back and changing old design decisions, we have to look at if and h=
ow we should evolve from where we are now=2E I think removing this behaviou=
r, even if we found something nicer to replace legitimate uses with, would =
be a huge compatibility break, for very little gain, so is unlikely to get =
anywhere=2E

Regards,

--=20
Rowan Collins
[IMSoP]