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
You can use the "static" late static binding keyword for this, it works,
see:
On Mon, Feb 25, 2013 at 11:00 AM, Jens Riisom Schultz ibmurai@me.comwrote:
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
2013/2/25 Jens Riisom Schultz ibmurai@me.com
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" */ }}
?>
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
--
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
--
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.
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 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
--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.
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
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
--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.
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, usingtoken_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
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
--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
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
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, usingtoken_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 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
--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 itexecutes 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 - G8HFLContact - http://lsces.co.uk/wiki/?page=**contacthttp://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
Benjamin Eberlei wrote:
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
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:
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 - G8HFLContact - 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
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 ....
Benjamin Eberlei wrote:
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
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
2013.02.26. 19:00, "Ralph Schindler" ralph@ralphschindler.com ezt írta:
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 isI 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?
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
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
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
--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.