> > I have been considering a "clean up reflection's class hierarchy" RFC > myself; things like getName() are also ubiquitous, but AFAICT is not > actually in a common type definition anywhere. > I think a single RFC to clean up all the bits is probably the place to > start. If any particular part of it ends up being controversial we can > consider splitting it off then.
Sounds good to me. I'll work on something along those lines and Shoot me an email off list sometime in March as a reminder and let's see > what we can figure out. :-) Or stop by the room 11 chat room. > get in touch with you sometime after mid of this month! Em qua., 2 de mar. de 2022 às 00:35, Larry Garfield <la...@garfieldtech.com> escreveu: > On Tue, Mar 1, 2022, at 2:02 PM, DANIEL VARGAS MUCCILLO wrote: > >> > >> I *think* all Reflector children support attributes, so it may not > need a > >> separate interface. > > > > > > ReflectionZendExtension and ReflectionExtension are currently the only > ones > > who implement Reflector but don't support attributes. > > > > > >> However, the entire Reflection class hierarchy is a mess and needs a > >> number of additional interfaces added to it generally. It makes sense > to > >> overhaul it holistically to make sure it all fits together. > >> > > > > Was not aware of other cases, but a quick look led to: > > > > - getExecutingFile() : string and getExecutingLine() : int in > > ReflectionFiber and ReflectionGenerator; > > - getDocComment() : string|false in ReflectionClass, > > ReflectionClassConstant, ReflectionFunctionAbastract and > ReflectionProperty; > > - getName(), getNameSpaceName() and getModifiers() in some cases (not > > always together). > > > > Should it be the case to expand the scope to handle these in the same > > proposal or maybe create a Meta RFC and discuss each on their own? > > I have been considering a "clean up reflection's class hierarchy" RFC > myself; things like getName() are also ubiquitous, but AFAICT is not > actually in a common type definition anywhere. > > I think a single RFC to clean up all the bits is probably the place to > start. If any particular part of it ends up being controversial we can > consider splitting it off then. > > >> I have zero availability until mid-March, but I'm open to helping at > that > >> point. > > > > > > Thanks for your return on that, I'll try to run at least a little on my > own > > foot until there, so I can be less of a burden! > > Shoot me an email off list sometime in March as a reminder and let's see > what we can figure out. :-) Or stop by the room 11 chat room. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Daniel Vargas Muccillo
