Re: [PHP-DEV] Possible improvements to the Reflection functionality

2022-05-07 Thread Ollie Read
Hey again!
> 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.)

Yeah, the idea behind getNumberOfAttributes was merely because it doesn't hurt 
to have, and since we're dealing with having 1 or more of a particular type of 
attribute, there are absolutely going to be times when has and get won't cut 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.

I'm super new to the list, in fact, this was my first interaction with it at 
all. My C-fu is practically non-existent, in fact, the first thing I ever did 
with C in my entire life, was the PR to fix the bug with closure attributes. 
That being said, I'm fairly confident that I have a decent understanding of how 
the reflection parts of the codebase work, and I've spent enough time poking 
around it that I think I know how to do most of what I have suggested.

> 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.

That's a good point. I'd be inclined to, at the very least, create two RFCs, 
one for types, and one for attributes, as while they both use reflection, 
they're very different points that are only connected in that they're part of 
reflection.

Since posting the original list, I even came up with an idea to expand on the 
typing, and introduce actual classes for each of the "types" (perhaps an enum), 
that the reflection types can use. I think that would be super useful for a lot 
of stuff, all the way from dependency injection to static analysis. Something 
like https://docs.microsoft.com/en-us/dotnet/api/system.type?view=net-6.0, but 
we could probably just make the reflection classes use that.

I'd also like to see the Reflection prefix dropped and proper namespacing 
introduced, but I also know that's not going to go down well with a lot of 
people.

Am happy to hear any suggestions or input, especially how people feel about the 
whole RFC side of things.

---
Best Regards,
*Ollie Read*


Re: [PHP-DEV] Possible improvements to the Reflection functionality

2022-05-07 Thread Larry Garfield
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