Tal,
I guess you just want to find out which classes an extension defines.
I don't think the current architecture allows for it.
There are two ways of going about it:
-
Keep track of extension classes with a HashTable (or list) in
zend_module_entry. This list would be updated when
zend_register_internal_class() is called. -
Add a field called module_number to zend_class_entry.
I think the first one would be more appropriate, but I welcome other
comments.
-Andrei http://www.gravitonic.com/
For society, it's probably a good thing that engineers value function over
appearance. For example, you wouldn't want engineers to build nuclear power
plants that only look like they would keep all the radiation inside.
(Scott Adams - The Dilbert principle)
Tal,
I guess you just want to find out which classes an extension defines.
I don't think the current architecture allows for it.There are two ways of going about it:
Keep track of extension classes with a HashTable (or list) in
zend_module_entry. This list would be updated when
zend_register_internal_class() is called.Add a field called module_number to zend_class_entry.
I think the first one would be more appropriate, but I welcome other
comments.
What about adding an introspection element to the zend_module_entry,
that would allow it to serve up such information per-request. This way
private functions could be hidden, necessary classes and datastructures
could be exposed, and it would be extensible to boot?
-Sterling
-Andrei http://www.gravitonic.com/
For society, it's probably a good thing that engineers value function over
appearance. For example, you wouldn't want engineers to build nuclear power
plants that only look like they would keep all the radiation inside.
(Scott Adams - The Dilbert principle)
--
"Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it."
- Richard Feynman
At 20:30 17.03.2003, Andrei Zmievski wrote:
Tal,
I guess you just want to find out which classes an extension defines.
I don't think the current architecture allows for it.There are two ways of going about it:
Keep track of extension classes with a HashTable (or list) in
zend_module_entry. This list would be updated when
zend_register_internal_class() is called.Add a field called module_number to zend_class_entry.
I think the first one would be more appropriate, but I welcome other
comments.
You forgot about one idea i do like much more: registering extension
classes in a seperate namespace (e.g.: the extension name).
Besides that the idea is really cool and improves introspection. What
about adding a SHORT textual info to the function/class members?
marcus
You forgot about one idea i do like much more: registering extension
classes in a seperate namespace (e.g.: the extension name).
That may be nice, but requires an active effort on the extension
authors' part.
Besides that the idea is really cool and improves introspection. What
about adding a SHORT textual info to the function/class members?
Like a "doc comment" you mean? :)
-Andrei http://www.gravitonic.com/
"Later in this talk, I intend to define
the universe and give three examples." -- Larry Wall
Tal,
I guess you just want to find out which classes an extension defines.
I don't think the current architecture allows for it.There are two ways of going about it:
- Keep track of extension classes with a HashTable (or list) in
zend_module_entry. This list would be updated when
zend_register_internal_class() is called.
This way looks ok to me too. I think it can be done by adding an HashTable
of zend_class_entry's to the zend_module_entry and then passing its
address to zend_register_internal_class (which will update it).
The only problem with that is that it will require modifying any extension
that registers classes.
Tal
-Andrei http://www.gravitonic.com/
For society, it's probably a good thing that engineers value function over
appearance. For example, you wouldn't want engineers to build nuclear power
plants that only look like they would keep all the radiation inside.
(Scott Adams - The Dilbert principle)--
--
Tal Peer
tal@php.net