Hello Internals
I've been reading some over the reflection sources, and theres a few
things that made me wonder abit;
-
ReflectionParameter::getDefaultValue(), was added to HEAD in 2006,
but never merged to a stable branch? I made a backport of the function
to 5.3 [1] which I think we should merge, whether its gonna be 5.3.1
or what. -
_default_lookup_entry() is commented out by a macro in HEAD but is
used in 5.3, and the only difference is the zend_hash_find ->
zend_u_hash_find call for unicode? -
Closures, theres alot of closure differences in HEAD and 5.3, for
example HEAD has ReflectionMethod::getClosure() and
ReflectionFunction::getClosureThis(), but 5.3 does not, which makes it
looks like a change in 5.3 that never occured to HEAD, unless that is
the logic is fixed in HEAD. We should really fix this, so 5.3 have
these if needed. -
How about an ReflectionNamespace, to analyze a namespace? Since
theres no real way to use reflection on namespaces other than the
"isNamespace" methods etc.
On a related note, I'd also like to propose an addition for
reflection, whether its 5.3.1 or what (since we're so late in 5.3,
theres no need to push more features), this is 3 new methods to the
ReflectionExtension class[2]:
ReflectionExtension::isDynamicLoaded() - Returns if an extension was
loaded through dl()
ReflectionExtension::getBuildId() - Gets the zend build id (added in 5.3)
ReflectionExtension::getAPINo() - Gets the zend api no that the
extension was compiled for (may not really be needed, since the number
doesn't change very often nor may be of any real use)
[1] http://pastie.org/474289
[2] http://pastie.org/474293
--
Kalle Sommer Nielsen
kalle@php.net
Hi Kalle,
- Closures, theres alot of closure differences in HEAD and 5.3, for
example HEAD has ReflectionMethod::getClosure() and
ReflectionFunction::getClosureThis(), but 5.3 does not, which makes it
looks like a change in 5.3 that never occured to HEAD, unless that is
the logic is fixed in HEAD. We should really fix this, so 5.3 have
these if needed.
The reason for this is that I removed $this and OOP support from closures
on Johannes's and Lukas's request in 5.3 since there was no consensus
on how this should actually work (see [1]). I didn't revert in HEAD
because there was at least consensus on the fact that someday in the
future Closures should support OOP/$this after we decide how. The
discussion on that topic has not progressed, however - nobody actually
reacted to my explanation on this topic (see [2]) - even after the
removal in 5.3 (which was done in order to allow the discussion to
progress independently of 5.3 so that a solution is not forced due to
time constraints).
My rationale for not removing it from HEAD was the simple fact that I
thought the discussion on this topic would progress and after 5.3 we
would reach a consensus on how to implement that. In that case, the
code in HEAD would have only needed to be changed, but not re-added.
I did not anticipate that the discussion would die down completely
for so long and that no progress would be made in that case.
Anyway, we have the following two options for HEAD:
-
Sync HEAD with 5.3 and remove that stuff also. Which could lead
to additional, unecessary work after we decide which way we want
to go.
- Leave it as is until we have decided.
Anyway, if anybody wants to renew the discussion on this topic, look
at [2] where all the details and problems are explained.
[1] http://wiki.php.net/rfc/closures/removal-of-this
[2] http://wiki.php.net/rfc/closures/object-extension
(please ignore "timeline" in the second link,
it's outdated)
Regards,
Christian
(re-sending, sorry if this arrives twice)
Hi,
- ReflectionParameter::getDefaultValue(), was added to HEAD in 2006,
but never merged to a stable branch? I made a backport of the function
to 5.3 [1] which I think we should merge, whether its gonna be 5.3.1
or what.
This should be low risk as it's a self-contained function and we all est
HEAD ... but I'd prefer not adding anything but bug fixes to 5.3 as it
already took way too long.
- _default_lookup_entry() is commented out by a macro in HEAD but is
used in 5.3, and the only difference is the zend_hash_find ->
zend_u_hash_find call for unicode?
Didn't take a look at the code so can't say much
- Closures, theres alot of closure differences in HEAD and 5.3, for
example HEAD has ReflectionMethod::getClosure() and
ReflectionFunction::getClosureThis(), but 5.3 does not, which makes it
looks like a change in 5.3 that never occured to HEAD, unless that is
the logic is fixed in HEAD. We should really fix this, so 5.3 have
these if needed.
At least getClosureThis() depends on $this handling which was reverted
from 5.3.
Not sure what getClosure() does.
- How about an ReflectionNamespace, to analyze a namespace? Since
theres no real way to use reflection on namespaces other than the
"isNamespace" methods etc.
We have no real namespace meta-data available, the only way doing things
there would be by iterating over the class table and parsing the class
names. Not usre that's really a good thing to do.
On a related note, I'd also like to propose an addition for
reflection, whether its 5.3.1 or what (since we're so late in 5.3,
theres no need to push more features), this is 3 new methods to the
ReflectionExtension class[2]:ReflectionExtension::isDynamicLoaded() - Returns if an extension was
loaded throughdl()
I was under the impression this was possible, or is it only printed by
export()?
ReflectionExtension::getBuildId() - Gets the zend build id (added in
5.3)
ReflectionExtension::getAPINo() - Gets the zend api no that the
extension was compiled for (may not really be needed, since the number
doesn't change very often nor may be of any real use)
I don't think this belongs to that class as these values should match
the one PHP was compiled with, so I think this should be a global
function.
johannes
Hi Johannes
2009/5/11 Johannes Schlüter johannes@php.net:
(re-sending, sorry if this arrives twice)
Hi,
This should be low risk as it's a self-contained function and we all est
HEAD ... but I'd prefer not adding anything but bug fixes to 5.3 as it
already took way too long.
We can always just merge it in 5.3.1 if your fine with it, seems
stupid to have a method there in a branch which isn't anywhere soon
(but hopefully im wrong), but nonetheless.
Didn't take a look at the code so can't say much
At least getClosureThis() depends on $this handling which was reverted
from 5.3.
Not sure what getClosure() does.
As said on irc, then yea getClosure() can be used to create a closure
of the function instance:
function greet($who) {
echo 'Greetings ' . $who;
}
$rf = new ReflectionFunction('greet');
$greet = $rf->getClosure();
$greet('Johannes');
I will have a look and reply to Christians mail once I've read and
understood the $this handling with closures, but I sort of see why its
not reverted there yet.
We have no real namespace meta-data available, the only way doing things
there would be by iterating over the class table and parsing the class
names. Not usre that's really a good thing to do.
It just seems odd that we have reflection for almost class, function
etc. elements but not namespaces, whereas it could be so simple as:
class ReflectionNamespace {
public $name;
public $absolute_path;
public function __construct($absolute_path_or_inherited_name);
ReflectionClass[] public function getClasses();
ReflectionFunction[] public function getFunctions();
array public function getConstants();
int public function getLine();
string public function getFile();
bool public function isAutoLoaded();
/* etc */
}
And then change inNamespace() to return:
ReflectionNamespace public function inNamespace()
or add an additional parameter/method to do so.
I was under the impression this was possible, or is it only printed by
export()?
I see it being printed in _extension_string(), but I don't see any
other references to how you may obtain that value. But if you like I
can add it (perhaps together with getDefaultValue) in 5.3.1.
I don't think this belongs to that class as these values should match
the one PHP was compiled with, so I think this should be a global
function.
After looking some more on it, then I agree, however the
isDynamicLoaded might be somewhat useful.
johannes
--
Kalle Sommer Nielsen
kalle@php.net