# Late FQCN resolution using ::class - Thread: https://externals.io/message/66178 - Original archive: https://news-web.php.net/php.internals/66178 - Started by Jens Riisom Schultz on 2013-02-25T10:00:04+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #66178 — Jens Riisom Schultz — 2013-02-25T10:00:04+00:00 URL: https://externals.io/message/66178#66178 Hi everybody, I have read up on this, and done some testing. First up, my findings with PHP5.5 alpha5: 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 --- ## #66179 — Benjamin Eberlei — 2013-02-25T10:07:06+00:00 URL: https://externals.io/message/66178#66179 · In reply to: #66178 You can use the "static" late static binding keyword for this, it works, see: http://3v4l.org/l9Z5Y On Mon, Feb 25, 2013 at 11:00 AM, Jens Riisom Schultz wrote: > Hi everybody, > > I have read up on this, and done some testing. > > First up, my findings with PHP5.5 alpha5: > > 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 --- ## #66180 — Sebastian Krebs — 2013-02-25T10:08:08+00:00 URL: https://externals.io/message/66178#66180 · In reply to: #66178 2013/2/25 Jens Riisom Schultz > Hi everybody, > > I have read up on this, and done some testing. > > First up, my findings with PHP5.5 alpha5: > > 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" */ > } > } > ?> > Without testing anything: My first idea would be 'static::class'. Did you tried this? > > 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 > -- > > > > -- github.com/KingCrunch --- ## #66181 — Nikita Nefedov — 2013-02-25T10:20:36+00:00 URL: https://externals.io/message/66178#66181 · In reply to: #66178 On Mon, 25 Feb 2013 14:00:04 +0400, Jens Riisom Schultz wrote: > Hi everybody, > > I have read up on this, and done some testing. > > First up, my findings with PHP5.5 alpha5: > > 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 > -- > > > 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. --- ## #66230 — Jens Riisom Schultz — 2013-02-26T07:25:21+00:00 URL: https://externals.io/message/66178#66230 · In reply to: #66181 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 > > > > […] > > 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. --- ## #66232 — Benjamin Eberlei — 2013-02-26T09:00:08+00:00 URL: https://externals.io/message/66178#66232 · In reply to: #66230 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. > 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 > > > > > […] > wrote: > > […] > 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. > > […] > support late FQCN resolution in any way? It would be very useful for > frameworks to be able to do this. > > […] > 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. --- ## #66233 — Lester Caine — 2013-02-26T09:08:20+00:00 URL: https://externals.io/message/66178#66233 · In reply to: #66232 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 !!!!! 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. > > > > > […] -- Lester Caine - G8HFL ----------------------------- 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 --- ## #66234 — Benjamin Eberlei — 2013-02-26T09:35:55+00:00 URL: https://externals.io/message/66178#66234 · In reply to: #66233 > 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: > > > […] > -- > Lester Caine - G8HFL > ----------------------------- > 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 Sorry, forgot to post inline. Thanks for mentioning it and doing it wrong > yourself, made me laugh ;-) But you are right. Actually if you check, it was quoted in the right place ;) But it is getting VERY annoying that a few people choose to ignore the lists requested style and blindly top post even when the discussion is nicely interleaved. It just does not work in these sort of discussions? :( I'd missed the significance of the initial thread but the problems of now documenting these sorts of 'changes' to language does need to be addressed? HOPEFULLY without forcing 'annotation' on us when there is already many years of good quality docblock documentation in many major libraries? -- Lester Caine - G8HFL ----------------------------- 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 --- ## #66236 — Pierre Joye — 2013-02-26T10:02:54+00:00 URL: https://externals.io/message/66178#66236 · In reply to: #66235 hi Lester, Please stop hijacking threads with all possible off topics and to use uppercase to improve your arguments (or lack of). Thanks for your understanding, take #42. > Benjamin Eberlei wrote: > > […] > > > Actually if you check, it was quoted in the right place ;) > > But it is getting VERY annoying that a few people choose to ignore the lists > requested style and blindly top post even when the discussion is nicely > interleaved. It just does not work in these sort of discussions? :( > > I'd missed the significance of the initial thread but the problems of now > documenting these sorts of 'changes' to language does need to be addressed? > HOPEFULLY without forcing 'annotation' on us when there is already many > years of good quality docblock documentation in many major libraries? > > -- > Lester Caine - G8HFL > ----------------------------- > 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 > > -- > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #66237 — Lester Caine — 2013-02-26T10:19:09+00:00 URL: https://externals.io/message/66178#66237 · In reply to: #66236 Pierre Joye wrote: > hi Lester, > > Please stop hijacking threads with all possible off topics and to use > uppercase to improve your arguments (or lack of). > > Thanks for your understanding, take #42. Get a life, actually read the discussion and follow the list RULES .... The question came up due to trying to handle namespace/class with phpdoc comments, so switching the thread to expand on that seems perfectly logical? Hence I've change the thread name .... > > > […] -- Lester Caine - G8HFL ----------------------------- 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 --- ## #66253 — Ralph Schindler — 2013-02-26T18:00:15+00:00 URL: https://externals.io/message/66178#66253 · In reply to: #66235 > I'd missed the significance of the initial thread but the problems of > now documenting these sorts of 'changes' to language does need to be > addressed? HOPEFULLY without forcing 'annotation' on us when there is I am still working on docs for this, perhaps if docs were not in SVN, things would be easier. I should have something by the weekend. -ralph --- ## #66258 — Ferenc Kovacs — 2013-02-26T21:28:04+00:00 URL: https://externals.io/message/66178#66258 · In reply to: #66253 2013.02.26. 19:00, "Ralph Schindler" ezt írta: > > > > […] > > > I am still working on docs for this, perhaps if docs were not in SVN, things would be easier. I should have something by the weekend. could you ellaborate? I fail to see why would the choice of vcs would matter in this. or maybe you are referring to the docbook format? --- ## #66259 — Ralph Schindler — 2013-02-26T21:38:38+00:00 URL: https://externals.io/message/66178#66259 · In reply to: #66258 > could you ellaborate? > I fail to see why would the choice of vcs would matter in this. > or maybe you are referring to the docbook format? I'm just out of practice with both SVN and docbook, as such, it's more of a chore to sit down and write/format/compile documentation than with git/markdown. I'm just complaining - don't mind me. -ralph --- ## #66314 — Jens Riisom Schultz — 2013-02-28T07:03:12+00:00 URL: https://externals.io/message/66178#66314 · In reply to: #66232 > 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). Thankyou for clarifying this. It was really all I wanted to know. I guess this discussion is dead (though it birthed a different discussion, which is also impossible to follow since it is laced with flames) I'm pulling out of this one. Thankyou all. > > 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. > > > > 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 > > > > > […]