Add get_object_constants and get_class_constants View as Markdown

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

Hi Crypto Compress,

big congratz to that name, your mummy Hash Compress and your daddy Image
Compress must be very proud!

SCNR

Am 02/27/2013 03:54 PM, schrieb Crypto Compress:

Hello Mike,

thank you! It is a useful feature to me.

class MyBitmask {
const POS_1 = 1;
// const POS_2 = 2; // reserved/undefined
// const POS_3 = 3; // reserved/undefined
const POS_4 = 4;

I'm developing software with PHP since version 2 and i'm still easily
impressed by such code. So we need get_object_constants and
get_class_constants for such fancy stuff?

Where's the good old
$flag == true; or FLAG == true;?

A bitmask class to shuffle around with class constants using reflection
of itself and a magic method get_class_constants to check a boolean flag?

I just don't get it but maybe i'm to focused to doing things the most
simple and readable/maintainable way.

Maybe, in a few years, c++ will be a beginners language compared to PHP
which gets added new shiny features every day which will only be used by
even more shiny frameworks and the most shiniest, bloated objects one
can imagine.

With every fancy feature added to PHP you kill a kitten!

I'm more with this "Give PHP and it's core developers a rest" so that
the core can be improved/cleaned up instead of adding Java features
people have seen on the university and like them but now they're forced
to use PHP which is like the opposite of Java. Java has it's good
reasons too. Just a tool. Use the tool that fits best, don't use the
hammer as a saw by adding teeth to it.

Cheers,
Frank

--

Frank Schenk
Software Analyst
2e Systems

Tel: +49 - 6196 - 95058 - 30
Fax: +49 - 6196 - 95058 - 94
E-mail: frank.schenk@2e-systems.com

Address: 2e Systems GmbH, Königsteiner Str. 87, D-65812 Bad Soden am Taunus
Company registration: Amtsgericht Königstein (Germany), HRB 7303
Director: Philip Douglas

http://www.2e-systems.com/ - making your business fly!