OBJECT_OPERATOR vs. DOUBLE_COLON

  99753
July 5, 2017 07:08 sebastian@php.net (Sebastian Bergmann)
Is it intentional that the DOUBLE_COLON operator can be used on a 
variable that contains a reference to an object?

) can be used 
on a variable that contains an object. https://3v4l.org/59Xap proved me 
wrong.

As the deprecation / strict standards notices suggest, though, $c::m() 
does not invoke the method m() on the object referenced by $c. It 
invokes the method statically on C (the class of the object referenced 
by $c): https://3v4l.org/19taB

I think that using :: on a variable that contains an object should not 
"fall back" to a static access on the object's class. Instead the 
runtime should error out.

What do you think?
  99757
July 5, 2017 10:24 rowan.collins@gmail.com (Rowan Collins)
On 5 July 2017 08:08:48 BST, Sebastian Bergmann <sebastian@php.net> wrote:
>Is it intentional that the DOUBLE_COLON operator can be used on a >variable that contains a reference to an object? > >class C >{ > public function m() > { > print '*'; > } >} > >$c = new C; >$c::m(); > >Until yesterday I thought that only the OBJECT_OPERATOR (->) can be >used >on a variable that contains an object. https://3v4l.org/59Xap proved me > >wrong. > >As the deprecation / strict standards notices suggest, though, $c::m() >does not invoke the method m() on the object referenced by $c. It >invokes the method statically on C (the class of the object referenced >by $c): https://3v4l.org/19taB > >I think that using :: on a variable that contains an object should not >"fall back" to a static access on the object's class. Instead the >runtime should error out. > >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. The double-colon is technically the "Scope Resolution Operator", or internally T_PAAMAYIM_NEKUDOTAYIM (which does mean double-colon). It's described in the manual here: http://php.net/manual/en/language.oop5.paamayim-nekudotayim.php 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 is useful. For instance, accessing a class constant associated to some object when interacting with that object, e.g. "$foo->doThing($foo::MODE_X)". If we could only use it on class names, we'd have to use the "::class" operator to go from one to the other, like "$foo::class::MODE_X"; or perhaps we'd change that operator too and write "$foo->class::MODE_X". That's not awful, I suppose, but it doesn't feel like a big gain. We'd also need to consider the consistency of "parent::", which resolves the scope but *doesn't* force a static access, because you need to be able to call an inherited non-static member. Like most established languages and frameworks, we don't have the luxury of going back and changing old design decisions, we have to look at if and how we should evolve from where we are now. I think removing this behaviour, 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. Regards, -- Rowan Collins [IMSoP]
  99760
July 5, 2017 12:28 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
On Mi, 2017-07-05 at 11:24 +0100, Rowan Collins wrote:
> 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. The double-colon is technically the "Scope > Resolution Operator", or internally T_PAAMAYIM_NEKUDOTAYIM (which > does mean double-colon). It's described in the manual here:  http://p > hp.net/manual/en/language.oop5.paamayim-nekudotayim.php >
We use T_DOUBLE_COLON in reflection: ext/tokenizer/tokenizer_data.c: REGISTER_LONG_CONSTANT("T_DOUBLE _COLON", T_PAAMAYIM_NEKUDOTAYIM, CONST_CS | CONST_PERSISTENT); ext/tokenizer/tokenizer_data.c: case T_PAAMAYIM_NEKUDOTAYIM: return "T_DOUBLE_COLON"; and I believe it appears/appeared in other places, too. johannes
  99767
July 5, 2017 15:24 rowan.collins@gmail.com (Rowan Collins)
On 5 July 2017 13:28:29 BST, "Johannes Schlüter" <johannes@schlueters.de> wrote:
>On Mi, 2017-07-05 at 11:24 +0100, Rowan Collins wrote: >> 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. The double-colon is technically the "Scope >> Resolution Operator", or internally T_PAAMAYIM_NEKUDOTAYIM (which >> does mean double-colon). It's described in the manual here:  http://p >> hp.net/manual/en/language.oop5.paamayim-nekudotayim.php >> > >We use T_DOUBLE_COLON in reflection: > >ext/tokenizer/tokenizer_data.c: REGISTER_LONG_CONSTANT("T_DOUBLE >_COLON", T_PAAMAYIM_NEKUDOTAYIM, CONST_CS | CONST_PERSISTENT); >ext/tokenizer/tokenizer_data.c: case >T_PAAMAYIM_NEKUDOTAYIM: return "T_DOUBLE_COLON"; > >and I believe it appears/appeared in other places, too.
Ah, OK, I stand corrected. Regards, -- Rowan Collins [IMSoP]
  99768
July 5, 2017 16:09 lauri.kentta@gmail.com (=?UTF-8?Q?Lauri_Kentt=C3=A4?=)
On 2017-07-05 18:24, Rowan Collins wrote:
> On 5 July 2017 13:28:29 BST, "Johannes Schlüter" > <johannes@schlueters.de> wrote: >> On Mi, 2017-07-05 at 11:24 +0100, Rowan Collins wrote: >>> 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. The double-colon is technically the "Scope >>> Resolution Operator", or internally T_PAAMAYIM_NEKUDOTAYIM (which >>> does mean double-colon). It's described in the manual here:  http://p >>> hp.net/manual/en/language.oop5.paamayim-nekudotayim.php >>> >> >> We use T_DOUBLE_COLON in reflection: >> >> ext/tokenizer/tokenizer_data.c: REGISTER_LONG_CONSTANT("T_DOUBLE >> _COLON", T_PAAMAYIM_NEKUDOTAYIM, CONST_CS | CONST_PERSISTENT); >> ext/tokenizer/tokenizer_data.c: case >> T_PAAMAYIM_NEKUDOTAYIM: return "T_DOUBLE_COLON"; >> >> and I believe it appears/appeared in other places, too. > > Ah, OK, I stand corrected. > > Regards,
I'm just wondering if T_PAAMAYIM_NEKUDOTAYIM could finally be changed to T_DOUBLE_COLON in, say, PHP 8? Sorry about hijacking this. :) -- Lauri Kenttä
  99770
July 5, 2017 16:47 zeev@zend.com (Zeev Suraski)
> On 5 Jul 2017, at 19:09, Lauri Kenttä kentta@gmail.com> wrote: > >> On 2017-07-05 18:24, Rowan Collins wrote: >>> On 5 July 2017 13:28:29 BST, "Johannes Schlüter" <johannes@schlueters.de> wrote: >>>> On Mi, 2017-07-05 at 11:24 +0100, Rowan Collins wrote: >>>> 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. The double-colon is technically the "Scope >>>> Resolution Operator", or internally T_PAAMAYIM_NEKUDOTAYIM (which >>>> does mean double-colon). It's described in the manual here: http://p >>>> hp.net/manual/en/language.oop5.paamayim-nekudotayim.php >>> We use T_DOUBLE_COLON in reflection: >>> ext/tokenizer/tokenizer_data.c: REGISTER_LONG_CONSTANT("T_DOUBLE >>> _COLON", T_PAAMAYIM_NEKUDOTAYIM, CONST_CS | CONST_PERSISTENT); >>> ext/tokenizer/tokenizer_data.c: case >>> T_PAAMAYIM_NEKUDOTAYIM: return "T_DOUBLE_COLON"; >>> and I believe it appears/appeared in other places, too. >> Ah, OK, I stand corrected. >> Regards, > > I'm just wondering if T_PAAMAYIM_NEKUDOTAYIM could finally be changed to T_DOUBLE_COLON in, say, PHP 8?
I for one would love not repeating that discussion once over... I realize some people aren't fond of this token, but it's at the level of harmlessness - and at least to some a part of the PHP folklore - that we should find better things to do than take another stab at removing it. Zeev
  99772
July 5, 2017 17:48 cmbecker69@arcor.de ("Christoph M. Becker")
On 05.07.2017 at 18:47, Zeev Suraski wrote:

>> On 5 Jul 2017, at 19:09, Lauri Kenttä kentta@gmail.com> wrote:>>>> I'm just wondering if T_PAAMAYIM_NEKUDOTAYIM could finally be changed to T_DOUBLE_COLON in, say, PHP 8?> > I for one would love not
repeating that discussion once over... I realize some people aren't fond of this token, but it's at the level of harmlessness - and at least to some a part of the PHP folklore - that we should find better things to do than take another stab at removing it. +1 -- Christoph M. Becker
  99773
July 5, 2017 17:48 cmbecker69@gmx.de ("Christoph M. Becker")
On 05.07.2017 at 18:47, Zeev Suraski wrote:

>> On 5 Jul 2017, at 19:09, Lauri Kenttä kentta@gmail.com> wrote:>>>> I'm just wondering if T_PAAMAYIM_NEKUDOTAYIM could finally be changed to T_DOUBLE_COLON in, say, PHP 8?> > I for one would love not
repeating that discussion once over... I realize some people aren't fond of this token, but it's at the level of harmlessness - and at least to some a part of the PHP folklore - that we should find better things to do than take another stab at removing it. +1 -- Christoph M. Becker
  99775
July 5, 2017 18:56 kalle@php.net (Kalle Sommer Nielsen)
2017-07-05 18:47 GMT+02:00 Zeev Suraski <zeev@zend.com>:
> I for one would love not repeating that discussion once over... I realize some people aren't fond of this token, but it's at the level of harmlessness - and at least to some a part of the PHP folklore - that we should find better things to do than take another stab at removing it.
Agreed. Even as a non native hebrew speaker (or speaker at all), I find this to be a part of PHP history, which we should not touch, and in the end, I find it kinda funny ;-) -- regards, Kalle Sommer Nielsen kalle@php.net
  99780
July 5, 2017 23:15 ajf@ajf.me (Andrea Faulds)
Hi Zeev,

Zeev Suraski wrote:
> >> On 5 Jul 2017, at 19:09, Lauri Kenttä kentta@gmail.com> wrote: >> I'm just wondering if T_PAAMAYIM_NEKUDOTAYIM could finally be changed to T_DOUBLE_COLON in, say, PHP 8? > > I for one would love not repeating that discussion once over... I realize some people aren't fond of this token, but it's at the level of harmlessness - and at least to some a part of the PHP folklore - that we should find better things to do than take another stab at removing it.
If we remove the name T_PAAMAYIM_NEKUDOTAYIM for :: then learning how to correctly pronounce it won't be fun anymore! But I'm a linguist, and you speak Hebrew, so maybe it's cruel on others ;) -- Andrea Faulds https://ajf.me/
  99758
July 5, 2017 10:34 danack@basereality.com (Dan Ackroyd)
On 5 July 2017 at 08:08, Sebastian Bergmann <sebastian@php.net> wrote:
> As the deprecation / strict standards notices suggest, > > What do you think?
It's been deprecated for years. An RFC to remove it would be appropriate to target PHP 8. I think nobody remembered to propose it for PHP 7. cheers Dan
  99779
July 5, 2017 23:12 ajf@ajf.me (Andrea Faulds)
Hi Sebastian,

Sebastian Bergmann wrote:
> Is it intentional that the DOUBLE_COLON operator can be used on a > variable that contains a reference to an object?
I assume so. It wouldn't be the only place that accepts either a class name or an object of that class.
> I think that using :: on a variable that contains an object should not > "fall back" to a static access on the object's class. Instead the > runtime should error out. > > What do you think?
I would oppose this; I think it would make PHP less consistent, and as Rowan noted, it's useful for accessing constants of the appropriate class associated to an object. Thanks! -- Andrea Faulds https://ajf.me/
  99781
July 5, 2017 23:46 kalle@php.net (Kalle Sommer Nielsen)
Hi Andrea, Sebastian

2017-07-06 1:12 GMT+02:00 Andrea Faulds <ajf@ajf.me>:
> Hi Sebastian, > > Sebastian Bergmann wrote: >> >> Is it intentional that the DOUBLE_COLON operator can be used on a >> variable that contains a reference to an object? > > > I assume so. It wouldn't be the only place that accepts either a class name > or an object of that class.
Thinking about it, couldn't this have been a side effect of the "Dynamic access to static methods", available as of PHP 5.3: -- regards, Kalle Sommer Nielsen kalle@php.net
  99782
July 6, 2017 04:46 smalyshev@gmail.com (Stanislav Malyshev)
Hi!

> I think that using :: on a variable that contains an object should not > "fall back" to a static access on the object's class. Instead the > runtime should error out.
Why should it not do what it does now? What would it achieve? I don't see any improvement in changing that - it may break code that is using this facility, and it won't make anything better. True, this is an exotic and non-obvious feature, but many languages have such features, which are used only by people that need them. If we proposed to add such feature, true, it may be too exotic to be added on its own merits, but since it is already there (and, probably, used in some code somewhere) - why bother messing with it? I don't see how just leaving it be hurts anything. -- Stas Malyshev smalyshev@gmail.com
  99829
July 11, 2017 02:37 php@bohwaz.net (BohwaZ/PHP)
Le 06/07/2017 16:46, Stanislav Malyshev a écrit :
> Hi! > >> I think that using :: on a variable that contains an object should not >> "fall back" to a static access on the object's class. Instead the >> runtime should error out. > > Why should it not do what it does now? What would it achieve? I don't > see any improvement in changing that - it may break code that is using > this facility, and it won't make anything better. True, this is an > exotic and non-obvious feature, but many languages have such features, > which are used only by people that need them. If we proposed to add > such > feature, true, it may be too exotic to be added on its own merits, but > since it is already there (and, probably, used in some code somewhere) > - > why bother messing with it? I don't see how just leaving it be hurts > anything.
True. I'm using that feature all the time to access static variables and constants, it's just more convenient to use the variable referencing the object than having to remember and type the name of the class (plus it's more obvious when reading the code back). Though I very rarely use it for accessing static methods, I don't see why this should throw an error, this feature makes sense as '::' is always for accessing static stuff, it is quite logic in the end: :: for static (constants, static variables, static methods) -> for the rest I think this feature is documented somewhere in the doc, that's where I learnt it from if I remember correctly.