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.
Best Regards,
Ollie Read
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/34c878bf120ee70f9d2a869cb7a242d1I'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
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