Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66248
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVpVpOmVneO=Qq=HQuMGQmpYLVFDbN=bq2Sy4VLfrzrsWg@mail.gmail.com>
References: <CALrkBja3i4Za=GE7QkbsnC-pa8ogkXdaQqqCWqOaA3s6srD_KA@mail.gmail.com>
	<CAF+90c8cShiOqKXGA+xyVjKtnpyvZ2cO=-EHc55zkLKxHBs7nA@mail.gmail.com>
	<CAESVnVpVpOmVneO=Qq=HQuMGQmpYLVFDbN=bq2Sy4VLfrzrsWg@mail.gmail.com>
Date: Tue, 26 Feb 2013 08:28:38 -0800
Message-ID: <CALrkBjYi7xYRwVr_0cmA0XgufuYf9jsF2ZXOtbVBa-9Ohi64+A@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044403ae6061c704d6a326e4
Subject: Re: [PHP-DEV] Add get_object_constants and get_class_constants
From: pencap@gmail.com (Mike Willbanks)

--f46d044403ae6061c704d6a326e4
Content-Type: text/plain; charset=UTF-8

> >> 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

--f46d044403ae6061c704d6a326e4--