Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:63006
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ralphschindler.com from 209.85.214.170 cause and error)
Message-ID: <5053497A.9070001@ralphschindler.com>
Date: Fri, 14 Sep 2012 10:12:58 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: internals@lists.php.net
References: <504F4D33.4070306@ralphschindler.com> <5051968E.7030908@zend.com> <5052474B.5050706@ralphschindler.com> <5052E5EC.2030103@zend.com> <CACwt+JdZzi6jRQAQwVw3YTaFsoziAvq8KVo2Nuu-0FjW8KK1yg@mail.gmail.com> <5052ED65.7020200@rotorised.com>
In-Reply-To: <5052ED65.7020200@rotorised.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [VOTE] ::class feature to resolve namespaced class
 names to scalars
From: ralph@ralphschindler.com (Ralph Schindler)


> I somewhat agree; using __CLASS__ would make it more obvious that it's
> compile-time rather than runtime, IMO.
>

It's not always going to be compile-time.

For self::class and Foo::class, it will be compile time every time.  For 
static:class and parent::class, that has to be done at runtime as the 
class_entry is not completely hooked up (active_class_entry does not 
have parent* pointer, even if the class is extended).

The 99% use case is: Foo::class, where a short name can be resolved 
against the current namespace and current import/use statements.

The rest of the use cases, as we've seen, are going to be filled out for 
consistency.

That means that:

class Foo {
   const SOMECLASSNAME = static::class; // or parent::class
}

Will/should result in an E_FATAL (this use case doesn't really make a 
ton of sense anyway, but people are likely to do it).

(I *think* the same applies for method signatures too, btw.)

>> That is the reason why I voted "no", but more because of the token
>> used than the feature.
>> I previously stated that I preferred __CLASS__ as well to be more in
>> line with what we currently have, I haven't changed my mind since the
>> arguments provided didn't convinced me at all.


I guess I can't convince preference :)

I prefer ::class over ::__class__, and in that only marginally, because 
its shorter.  After all, the whole point of this feature is because 
people are using namespaces (for the shortness of class names) and they 
need to use long class names as string, but want all the benefits of the 
namespacing/aliasing in the current scope.

-ralph