Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86394
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.175 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <556496B3.1030905@ralphschindler.com>
References: <55636034.6010003@mabe.berlin>
	<CAFMT4Nri34Ae-AdOxUY13La2QOC9OxbNGNce4X6ZRkYKNaeM-Q@mail.gmail.com>
	<556496B3.1030905@ralphschindler.com>
Date: Tue, 26 May 2015 11:51:44 -0600
Message-ID: <CAFMT4NqcpyYGYR74bUHJWZNu6ECaCbitWeJjqKodPU2KW1O12A@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] ::class wrong case
From: levim@php.net (Levi Morrison)

On Tue, May 26, 2015 at 9:52 AM, Ralph Schindler
<ralph@ralphschindler.com> wrote:
>
>
>> <?php
>>
>> namespace foo;
>>
>> function bar(){}
>>
>> var_dump(bar::class); // string(7) "foo\bar"
>>
>> ?>
>>
>> This was not explained in the RFC at all, and had I known this I would
>> have voted against it personally.
>
>
> How would you suggest it be different, if not a "compile-time name expansion
> for classes"?

Emit an opcode for it. This would also allow for dynamic lookups
($foo::class), trigger autoloading, and restrict it to classes and
interfaces (and traits?). All of these things are beneficial in my
opinion, at least.

> On a personal note, I've gotten plenty of benefit from the feature which
> (again, for me) totally eclipses the only very small regret that ::class
> looks like a class constant lookup.  That syntactical point could have gone
> either way, but I feel like the accepted syntax is still a good choice.

I have found this feature to be useful as well. The essence of this
feature is good, but I feel like the implementation is unfortunate.

> Your example above might attempt to cause some mis-direction to the reader
> of the code a bit because you have clearly defined a symbol (function)
> called "bar", yet you're still name-expanding a class called "bar", which
> technically could be living in the same namespace in a different file
> covered by an autoloader.  bar::class still does actually mean foo\bar the
> class, not the function.
>
> <?php
> namespace foo;
> function bar() {}
> class bar {}
> var_dump(bar::class); // string(7) "foo\bar"
> $b = new bar;
> var_dump(get_class($b));

bar::class does not necessarily mean `foo\bar` the class; it just does
a string expansion. In my opinion it should have been restricted to
only classes and interfaces (or other things like them) since that's
what the RFC and syntax intends, but not what it actually does.