Hi,
I'm curious whether the ORDER of the class properties returned by
get_class_vars(), is in some way guaranteed. I do not find mention of it
in the documentation.
I'm especially interested in the order of static class variables
returned.
Testing, using PHP 5.4.6, I find that there seems to be a stable order,
which suits my reasons for looking into this quite nicely. Here is what
I find:
- static properties defined directly in the class itself come first, in
definition (source) order - static properties defined directly in parent classes come next, in
definition order of their respective sources, and going up the class
tree. So grandparent properties come after parent properties - static properties contributed by traits, all come AFTER the properties
from the class source itself, including all ancestors - static properties contributed by a single trait come in definition
(source) order of that trait definition - with static properties from several traits, those of the HIGHEST
class in the inheritance tree some first, and those from the class
under inspection come last. This is exactly the opposite order of
what happens with properties from the classes themselves.
As it happens, the ordering I find for static properties contributed by
traits, is exactly what I was looking for. But is it guaranteed, or
could such a guarantee be made?
best regards
Patrick
Hi,
I'm curious whether the ORDER of the class properties returned by
get_class_vars(), is in some way guaranteed. I do not find mention of it
in the documentation.
The only real guarantee is that of how the class properties are stored
in the hashtable. get_class_vars() is essentially just reading from a
hashtable of class properties.
I'm especially interested in the order of static class variables
returned.Testing, using PHP 5.4.6, I find that there seems to be a stable order,
which suits my reasons for looking into this quite nicely. Here is what
I find:
- static properties defined directly in the class itself come first, in
definition (source) order- static properties defined directly in parent classes come next, in
definition order of their respective sources, and going up the class
tree. So grandparent properties come after parent properties- static properties contributed by traits, all come AFTER the properties
from the class source itself, including all ancestors- static properties contributed by a single trait come in definition
(source) order of that trait definition- with static properties from several traits, those of the HIGHEST
class in the inheritance tree some first, and those from the class
under inspection come last. This is exactly the opposite order of
what happens with properties from the classes themselves.As it happens, the ordering I find for static properties contributed by
traits, is exactly what I was looking for. But is it guaranteed, or
could such a guarantee be made?
The order they're stored in the hashtable is as you've pointed out
dependent on loading the definitions of the classes in the case of
class variables. However, it's not a guarantee that get_class_vars()
makes since it doesn't guarantee any order. It just so happens that it
also doesn't try to intercede in whatever order the class variables
are stored in in the hashtable.
It's not like depending on the order of class variable definitions is
something that crops up in any practical use cases that I've
encountered. I wouldn't depend on order too heavily here.
Anything were order is important to you should use an Array since
that's what a PHP Array type guarantees (i.e. order).
best regards
Patrick
I'm curious whether the ORDER of the class properties returned by
get_class_vars(), is in some way guaranteed. I do not find mention of it
in the documentation.The only real guarantee is that of how the class properties are stored
in the hashtable.get_class_vars()is essentially just reading from a
hashtable of class properties.
There's no such guarantee. The fact that it is using a Hashtable which has an order is an implementation detail. This might change (even though a change is unlikely) The only promise of get_class_vars() is to return all.
johannes
Hi,
Am 09.09.2012 um 13:52 schrieb Johannes Schlüter johannes@schlueters.de:
[...]
There's no such guarantee. The fact that it is using a Hashtable which has an order is an implementation detail. This might change (even though a change is unlikely) The only promise of
get_class_vars()is to return all.
Or put it that way: if you need a specific order, sort it "by code".
cu,
Lars
On Sun, Sep 9, 2012 at 7:52 AM, Johannes Schlüter
johannes@schlueters.de wrote:
I'm curious whether the ORDER of the class properties returned by
get_class_vars(), is in some way guaranteed. I do not find mention of it
in the documentation.The only real guarantee is that of how the class properties are stored
in the hashtable.get_class_vars()is essentially just reading from a
hashtable of class properties.There's no such guarantee. The fact that it is using a Hashtable which has an order is an implementation detail. This might change (even though a change is unlikely) The only promise of
get_class_vars()is to return all.
Right, I should have said "there's no guarantee at all", but what I
was trying to say was that this isn't really by guarantee of
get_class_vars(). Just the fact that this particular implementation
detail is unlikely to change is what makes it a convenient side
effect.
Sorry, that was poorly worded.
johannes
Can we use reflection to inspect the properties in the order that they're
written, or the order that the parser found public/protected/private
keywords and properties.
Paul.
On Sun, Sep 9, 2012 at 1:10 PM, Sherif Ramadan theanomaly.is@gmail.comwrote:
On Sun, Sep 9, 2012 at 7:52 AM, Johannes Schlüter
johannes@schlueters.de wrote:On Sep 9, 2012, at 10:22, Sherif Ramadan theanomaly.is@gmail.com
wrote:I'm curious whether the ORDER of the class properties returned by
get_class_vars(), is in some way guaranteed. I do not find mention of
it
in the documentation.The only real guarantee is that of how the class properties are stored
in the hashtable.get_class_vars()is essentially just reading from a
hashtable of class properties.There's no such guarantee. The fact that it is using a Hashtable which
has an order is an implementation detail. This might change (even though a
change is unlikely) The only promise ofget_class_vars()is to return all.Right, I should have said "there's no guarantee at all", but what I
was trying to say was that this isn't really by guarantee of
get_class_vars(). Just the fact that this particular implementation
detail is unlikely to change is what makes it a convenient side
effect.Sorry, that was poorly worded.
johannes
Thanks Sherif and all, for your answers.
So I will not rely on the order returned by get_class_vars (or
get_class_methods), instead adding suitable code (actually
roughly one additional line per class involved) to define my
desired ordering by hand.
If you're curious, the use case I was thinking of, arose when
implementing a logfile message formatting class hierarchy, where
subclasses represent individual logfiles with different pieces of
information that might be added to the logfile lines, in addition to the
base message - stuff like PHP_SELF, the calling user, memory usage etc.
I implement each of these different pieces as a separate trait with a
formatting function of a certain prefix, and imagined I could just use
the order of "use" statements in my subclasses, or as a proxy the method
order, to stably define the order in which the pieces will the show in
the logfile represented by that subclass.
Now, I add a static::$order array to each subclass, where I name the
pieces again (in addition to the use statements).
best regards
Patrick