> >> Before drafting an RFC I would like to gauge interest in adding:
> >> get_object_constants and get_class_constants
> >>
> >> I have already drafted up a PR with the changes and supplemental data:
> >> https://github.com/php/php-src/pull/292
> >>
> You took the time to make a PR, but not an RFC? This should really be
> the other way around (if at all).
>
Yeah, part of it is that I want to learn the internals so if I have to
throw it away; I don't care too much about it. Would be different if I
knew the internals far better than I do then I would likely start on that
path. But I wanted to be able to see what the performance differences
were, how to achieve it as I don't want to be one of those... yeah PHP
should do this but I can't do the work... so I figure I'd start by writing
it and finding help along the way until I can figure it out. :)
>
>
> >> Currently this can only be done through ReflectionClass which is far
> slower
> >> than retrieving them directly from the constants table. Some simple
> >> timings show that through reflection retrieving these values is 2-3
> times
> >> slower than providing a quick access function for retrieval.
> >>
> > I don't quite see why we need this. The only argument seems to be
> > performance and I'm not quite sure why performance would be relevant
> here.
> > At least I can't imagine in what kind of code fetching the class
> constants
> > is a bottleneck.
> >
> I'm meh on the perf issue. Yeah it's probably there, but it's buried
> in the noise and I'm not so sure about use-cases. Not against it for
> its own sake though.
>
Many open source projects frown on the usage of Reflection and
ReflectionClass inside of the code base; this is part of the reason. Sure
I could certainly use ReflectionClass and leverage that instead. The
perception is that Reflection* is slow and as such by most maintainers it
is advised to stay away from it unless you're caching the results. As
stated the performance is not necessarily a _huge_ case here; however, the
more places that this becomes incorporated in a code base the slower things
get overall.
Here is a simple use case of usage where MyClass2 can add in new constants
without having issue:
MyClass {
const SUCCESS = 1;
const FAILURE = -1;
const FAILURE_UNCATEGORIZED = -2;
public function __construct($code) {
$code = (int) $code;
if (!in_array($code, get_object_constants($this))) {
$code = self::FAILURE;
}
}
}
MyClass2 extends MyClass
{
const FAILURE_MYTYPE = -3;
}
>
> >> This also fits nicely amongst the current stack of:
> >> get_object_vars, get_class_vars and get_class_methods
> >>
> >
> Yay! Consistency! Boo! Poorly named get_*() methods should have been
> called something else from the get-go, but it's too late for that.
> Honestly, this is the bit that bugs me most.
>
Yeah; I just attempt to follow whatever is consistent in whichever area it
is.
I guess I am also curious here (not to divert from the thread) but if we do
not want to add in more of these; why don't we deprecate the usage of the
current get_class_vars, get_object_vars, get_class_methods, etc and attempt
to have everyone move over to the Reflection use case?
Obviously this would have to be in a major version but if as a language PHP
is moving things to the reflection use cases then provide it only there?
Seriously not attempting to open up a can of worms here; there has already
been several threads on BC and deprecation in the last month or so overall
on the ML.
>
> >> These functions are commonly asked about on areas such as StackOverflow
> (
> >>
> >>
> http://stackoverflow.com/questions/956401/can-i-get-consts-defined-on-a-php-class
> >> )
> >> amongst other places on the net.
> >>
> >
> I... kinda don't care about this part of the argument. It's called
> "Google", and if they can't find it in Reflection, they won't find it
> here.
>
That is semi true; I believe most people would locate
get_object_vars/get_class_vars and then are confused when they cannot get
the constants. Still it is easy to locate the reflection so this argument
is easily dropped.
- Mike
