Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62902
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: <504AD3C8.5090000@ralphschindler.com>
Date: Sat, 08 Sep 2012 00:12:40 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <4F89D4F1.8070009@ralphschindler.com> <4F8CEB3B.4080702@ralphschindler.com> <CAOWwgp=Bm2fmoAy9p_5VAeGGTYd61=4ooQL8+Fg2RQt+mySQPg@mail.gmail.com> <4F8DA14F.1030204@sugarcrm.com>	<B9.1A.03996.EF6AD8F4@pb1.pair.com> <4F8DCAC7.2050302@ralphschindler.com>	<4F8DF2B6.4030709@sugarcrm.com> <CAF+90c961FHeB_R82WANe6dtn+3ZOXbgUAGjDO=hSSAFXy_OtQ@mail.gmail.com> <4F8DFB17.7030509@sugarcrm.com> <CAF+90c9nT7LJ-jwK5NrBmj3E4PkPNrHnET2uTr44Pqy2itakkw@mail.gmail.com> <4F8F1D0C.2030904@sugarcrm.com>
In-Reply-To: <4F8F1D0C.2030904@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: New Feature: Fully qualified class name resolution
 as scalar with class keyword
From: ralph@ralphschindler.com (Ralph Schindler)

Hey Stas, et. al.,

I think I've addressed some of your concerns and completed this 
feature/patch.

   https://github.com/php/php-src/pull/187

More inline ...

>> But yes, I agree that runtime resolution only duplicates existing
>> behavior, so it isn't really necessary (you could argue thought that
>> self::class similarly also only replicates the existing __CLASS__). It
>> would be nice for consistency in my eyes, but I'm good without it too

The current patch allows for the following:

   self::class -> resolves to name in active_class_entry
   static::class -> resolves to FCALL get_called_class()
   parent::class -> resolves to FCALL get_parent_class()

I would have liked to have done parent::class w/o FCALL but the 
active_class_entry's parent is empty even when inside of a class 
extending another class.

> $foo::bar and $foo::class mean completely different things. foo::bar is
> static constant expression, so is foo::class, but static::class and
> $foo::class won't be. It all would be very confusing. I suggest limiting

$foo::class is not syntax that is currently handled (you will get a 
parse error: unexpected T_CLASS here.  I think that is what you were 
ultimately suggesting, no?

Feedback is welcome, either here or in the pull request.

Thanks!
Ralph