I really appreciate the thoughts & discussion--I'll put this to bed. Thank you for talking through it with me!
On Fri, Jun 12, 2020 at 10:11 AM Chuck Adams <cja...@gmail.com> wrote: > > > 1. It aligns with the addition of the functions referenced in the > original post (`str_[contains|starts_with|ends_with]()`), and one > their stated reasons of simplifying the API for userland developers. > > Two reactions to this: One, reflection isn't a facility for novices, > so there's no need to cater to it. If novices end up needing such a > method frequently, something else is wrong other than how accessible > that method is. > > Two, reflection being all about reflecting over objects and classes, > it seems reasonable to limit it to an OO API. Any existing global > functions in that arena should just be considered legacy. > ReflectionClass is not final, and I can see plenty of use cases for > subclassing it. > > On Thu, Jun 11, 2020 at 10:32 PM Troy McCabe <troy.mcc...@gmail.com> wrote: > > > > Hey Nikita, > > > > Thanks for the thoughts. > > > > > Could you please explain in more detail *why* we should duplicate > > > existing reflection functionality into free-standing functions? > > > > In terms of the *why*, there were three main reasons: > > 1. It aligns with the addition of the functions referenced in the > > original post (`str_[contains|starts_with|ends_with]()`), and one > > their stated reasons of simplifying the API for userland developers. > > While `(new \ReflectionClass(MyClass::class))->getConstants()` isn't > > the most difficult thing to grasp, it's not immediately clear to new > > developers, and is more verbose than > > `get_class_constants(MyClass::class)` > > 2. `get_class_[methods|vars]()` existing as built-in functions, > > creates a gap to retrieving class constants in the same way. If I > > start down the path of class inspection using `get_class_*()`, but > > find I can't retrieve constants in the same way, this is an > > inconsistency. > > 3. When using Reflection, accessibility is not respected as it is with > > the `get_class` family of functions. In the event that a developer is > > looking for constants which are accessible to the current context, > > there's no way (that I'm seeing, anyway) to retrieve _only_ constants > > accessible in the current context. > > > > > I believe the existence of functions like get_class_methods() is a > > > historical artifact, because they were introduced before Reflection was a > > > thing. Unless there is a strong reason to the contrary, I would prefer > > > reflection functionality to stay inside Reflection... > > > > This is good background that I wasn't aware of (I knew the Reflection > > API was newer than the built-in functions, but not that the > > `get_class_*` functions were generally frowned upon). > > > > It does bring up 2 questions: > > 1. Obviously this is a much larger discussion, but is there any > > appetite to deprecate & remove the existing functions in favor of the > > Reflection API? > > 2. An alternative to adding `get_class_constants()` would be to > > introduce `ReflectionConstant` as a return type from > > `ReflectionClass::getConstants` to match `ReflectionMethod` & > > `ReflectionProperty`, which would solve point 3 above. Would this be a > > preferable approach? > > > > > You do mention performance as a benefit, but it's not immediately obvious > > > to me which use-cases are bottlenecked by class constant reflection. > > > > Enum implementations are the big case for this. While the libs I've > > looked at use an internal cache, these caches are per-request, so > > reflection will need to be used as many times as there are enums in a > > given system. Depending on the scale, this could be an appreciable > > amount. Obviously external caches could be leveraged, but that then > > requires additional development lift, instead of using battle-tested > > enum libs. > > > > Thanks for the thoughts, and thank you for all your work on internals! > > Thanks! > > Troy McCabe > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
