Proposal for RFC: get_class_constants() View as Markdown

If it is the only reason you are having to activate reflections?
Reflections would seem to have a place, but is it really necessary to add
yet another layer when most of the time it's function is provided better by
IDE tools anyway? This is a simple example of a current hole in the core
PHP tools which would help a section of developers who don't need the
overheads of additional layers.

@Lester additional layer is still better than yet another shortcut.

Since we already have the feature, introducing another flavor for it seems
a bit of an overkill, especially if it also has to be maintained.

Any userland implementation can handle this by also being fast enuff:

function get_class_constants($className)
{
static $cached = [];

if (isset($cached[$className])) {
    return $cached[$className];
}

return $cached[$class] = (new \ReflectionClass($class))->getConstants();

}

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Troll much?

Anyways, along the rest of the thread, a function to support the people
working with objects that don't want to work with objects is a weak place
to argue from. However if we're keeping get_class_* methods, API completion
seems worthwhile.
On Dec 15, 2013 3:13 PM, "Crypto Compress" cryptocompress@googlemail.com
wrote:

Hi,

a short fairy tale:
For a long time thePHPway™ was to build a function for everything someone
needed/could imagine. This is why PHP is so easy, effective and triumphant.
But somehow the highlander principle found it's way into PHP and nothing
will ever be as it was before. So flog the reflection argument to death.

internals@lists.php.net/msg64242.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg64242.html

Cheers!
cryptocompress

Hi,

a short fairy tale:
For a long time thePHPway™ was to build a function for everything
someone needed/could imagine. This is why PHP is so easy, effective
and triumphant. But somehow the highlander principle found it's way
into PHP and nothing will ever be as it was before. So flog the
reflection argument to death.

internals@lists.php.net/msg64242.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg64242.html

Cheers!
cryptocompress

Buried in the excessive snark of this message is a useful piece of
information: the proposal has come up before, and an implementation was
even provided, along with a few use cases which might benefit from the
small performance improvement of having a direct implementation separate
from the full ReflectionClass.

It also reminded me of another use case: exceptions. Since the "code" of
an Exception has to be an integer, writing a readable summary of an
exception to a text-only log is tricky: if you just echo the code
itself, you'd have to go back to the source code (or phpdoc) to look up
its meaning. But when constructing an Exception, you will generally
use a class constant to specify the code. If you grab all the class
constants of the particular Exception sub-class, you can - hopefully -
find the one with the appropriate value, and write its name to the log,
rather than the number.

That look-up may well happen every time you push an exception into the
logging handler, so keeping it high-performance is probably a good idea.
I suspect there are other slow points of such a function, but if
constructing a ReflectionClass carries an inherent cost, it would be
nice to avoid doing so.

Regards,

--
Rowan Collins
[IMSoP]