On Thu, May 5, 2022, at 12:04 PM, Ollie Read wrote:
> Hello all,
>
> I've been spending a lot of time in the world of PHP reflection lately, 
> which has led me to create PRs for the documentation, a bug for closure 
> attributes, and even a new method on ReflectionMethod. I've also 
> compiled a list of suggestions for various additions and improvements 
> to some parts of reflection. 
>
> You can find it here: 
> https://gist.github.com/ollieread/34c878bf120ee70f9d2a869cb7a242d1
>
> I'm looking for some feedback on the various elements and some 
> guidance, if any have merit, as to whether they're going to require any 
> sort of RFC. I'm also happy to create PRs for some of the features, if 
> not all, though I think there are definitely some beyond my current 
> knowledge. I would also be interested in hearing from anyone who also 
> has other suggestions that could be added to this.
>
> Apologies if I'm missing something, or I could have done something 
> better, this is my first interaction with this mailing list, so I am 
> also happy to receive any feedback about the best approaches and ways 
> to handle things, if necessary.

Greetings.

I've also been doing a lot of work with Reflection lately as part of 
https://github.com/Crell/AttributeUtils .  I agree with and support almost all 
of these additions.  (I'm no entirely convinced by getNumberOfAttributes(), but 
I don't really see a harm in it.)

There was another short thread on the list back in February?, I think, about 
some improvements to reflection.  We desperately need a few more well-placed 
interfaces and stubs for things like attributes, and even getName().  My C-fu 
is paltry if I'm being polite, but I'm happy to help with process and RFC 
writing/documentation.  The Reflection API is badly in need of some love.

In practice, I think most of these would require RFCs.  The question is whether 
they're better as a bunch of stand-alone RFCs or one big "clean up Reflection" 
RFC or a series of "clustered" RFCs.  I'm not sure what's most palatable to 
folks these days.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to