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 

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 

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

Best Regards,
*Ollie Read*

Reply via email to