Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66234
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain beberlei.de from 74.125.82.182 cause and error)
MIME-Version: 1.0
In-Reply-To: <512C7B84.7040405@lsces.co.uk>
References: <01F30F77-B22D-40CE-ADF1-AC1C488FE39D@me.com>
	<op.ws14cmnkc9evq2@nikita2206-n56vj>
	<5F87647B-339F-48A1-82B3-E210F95766CD@me.com>
	<CAEPJdun+JqDyF-AU8wmMNaFEB8-ZXHStT-O=YK6_QyjXQ3wvvg@mail.gmail.com>
	<512C7B84.7040405@lsces.co.uk>
Date: Tue, 26 Feb 2013 10:35:55 +0100
Message-ID: <CAEPJdumufTp2nGB2fKgz+sNEz0cGXzTcUm-UP3Ff6Z2zbiO+bA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d043c80da5c160b04d69d62e6
Subject: Re: [PHP-DEV] Late FQCN resolution using ::class
From: kontakt@beberlei.de (Benjamin Eberlei)

--f46d043c80da5c160b04d69d62e6
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 26, 2013 at 10:08 AM, Lester Caine <lester@lsces.co.uk> wrote:

> This is an interesting discussion, and since I use phpdoc extensively,
> it's an area that I have been thinking about, but WHY do you have to make
> it so difficult to follow by simply bundling more text at the top. THIS
> needs to be quoted properly and THEN perhaps other people can follow the
> discussion. Try reading the rest of this message when you don't know what
> came before !!!!!


Sorry, forgot to post inline. Thanks for mentioning it and doing it wrong
yourself, made me laugh ;-) But you are right.

>
>
> Benjamin Eberlei wrote:
>
>> This is indeed not possible, because strings are not class context
>> independent, you can pass them to anywhere. A string just doesn't know
>> what
>> namespace it belongs to and this does not make sense without providing
>> more
>> context in client libraries (such as docblocks).
>>
>> Also the use statement information is NOT available in the engine, because
>> its resolved way before in the compiling step (as far as i understood it).
>>
>> What Doctrine Annotations does to solve this is parsing this information
>> ourselves, using token_get_all(), then caching this information on a per
>> file basis.
>>
>> On Tue, Feb 26, 2013 at 8:25 AM, Jens Riisom Schultz <ibmurai@me.com>
>> wrote:
>>
>>  Ok I get that, thankyou for the explanation.
>>>
>>> static::class is not an option. I'm trying to resolve class names defined
>>> in docblocks, since phpdoc2 allows for entering type hints (classes) as
>>> namespace/use relative. And I can tell there is no current way of
>>> resolving
>>> class names in strings, to FQCN's, unless I'm missing something? (There
>>> is
>>> no way to get a list of the currently used namespaces as far as I can
>>> tell
>>> - would such a function be possible to add to the SPL, without any major
>>> rewriting?)
>>>
>>> So, I'm simply wondering if this would require any major rewriting to
>>> support? Otherwise I could look into it and try to write a patch...
>>> Because
>>> I think this would be really useful for framework developers, php unit
>>> testing and php doc for example.
>>>
>>> -Jens
>>>
>>> On Feb 25, 2013, at 11:20 AM, Nikita Nefedov <inefedor@gmail.com> wrote:
>>>
>>>  On Mon, 25 Feb 2013 14:00:04 +0400, Jens Riisom Schultz <ibmurai@me.com
>>>> >
>>>>
>>> wrote:
>>>
>>>>
>>>>  Hi everybody,
>>>>>
>>>>> I have read up on this, and done some testing.
>>>>>
>>>>> First up, my findings with PHP5.5 alpha5:
>>>>>
>>>>> <?php
>>>>> namespace spacy;
>>>>>
>>>>> class classy {
>>>>>         public static function fqcn() {
>>>>>                 /* This works but is not useful enough: */
>>>>>                 //return self::class;
>>>>>
>>>>>                 $me = 'classy';
>>>>>
>>>>>                 /* This just doesn't work, but I wish it did: */
>>>>>                 //return $me::class;
>>>>>
>>>>>                 /* This simply does not work as expected: */
>>>>>                 return eval("return $me::class;");
>>>>>                 /* Output: "classy" - Expected output: "spacy\classy"
>>>>> */
>>>>>         }
>>>>> }
>>>>> ?>
>>>>>
>>>>> I'm trying to late resolve a class name contained in a variable to the
>>>>>
>>>> FQCN. I understand that this is hard (maybe even impossible) with the
>>> current implementation, because class name resolution happens compile
>>> time,
>>> but eval("return $me::class;") simply returns something that is weird.
>>>
>>>>
>>>>> I guess what I'm trying to ask is whether it would be impossible to
>>>>>
>>>> support late FQCN resolution in any way? It would be very useful for
>>> frameworks to be able to do this.
>>>
>>>>
>>>>> - Jens Riisom Schultz
>>>>> --
>>>>> PHP Internals - PHP Runtime Development Mailing List
>>>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>>>
>>>>>
>>>> Hi Jens,
>>>>
>>>> Here's what happened in your code:
>>>> When you invoked fqcn(), you created var $me = "classy";
>>>> Then you tried to invoke this code in eval: "return classy::class;"
>>>> But when php evals code, it's like including another file. So it
>>>>
>>> executes the code without any namespace (it's in global namespace), and
>>> php
>>> didn't discover class with name classy (there's only spacy\classy) yet,
>>> so
>>> it tries to resolve all your "use" statements (but you didn't write any)
>>> and then just gives you "classy", it didn't throw any error just because
>>> it
>>> tried to delay autoloading of this class as far as possible, if would do
>>> eval("return new $me;") then you would get fatal error.
>>>
>>
> --
> Lester Caine - G8HFL
> -----------------------------
> Contact - http://lsces.co.uk/wiki/?page=**contact<http://lsces.co.uk/wiki/?page=contact>
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.**uk<http://rainbowdigitalmedia.co.uk>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f46d043c80da5c160b04d69d62e6--