>> 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).
>> 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. >> 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. >> 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. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
