# Reflection

- Thread: https://externals.io/message/43881
- Original archive: https://news-web.php.net/php.internals/43881
- Started by Kalle Sommer Nielsen on 2009-05-11T10:34:14+00:00
- Messages: 4
- 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

---

## #43881 — Kalle Sommer Nielsen — 2009-05-11T10:34:14+00:00

URL: https://externals.io/message/43881#43881

Hello Internals

I've been reading some over the reflection sources, and theres a few
things that made me wonder abit;

1) 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.

2) _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?

3) 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.

4) 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

---

## #43883 — Christian seiler — 2009-05-11T12:12:21+00:00

URL: https://externals.io/message/43881#43883 · In reply to: #43881

Hi Kalle,



> 3) 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:



 1. 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.



 2. 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

---

## #43884 — johannes@php.net — 2009-05-11T12:18:10+00:00

URL: https://externals.io/message/43881#43884 · In reply to: #43881

(re-sending, sorry if this arrives twice)

Hi,


> 1) 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.

> 2) _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

> 3) 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.

> 4) 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 through `dl()`

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

---

## #43894 — Kalle Sommer Nielsen — 2009-05-12T07:52:10+00:00

URL: https://externals.io/message/43881#43894 · In reply to: #43884

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