Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117690
User-Agent: Cyrus-JMAP/3.7.0-alpha0-591-gfe6c3a2700-fm-20220427.001-gfe6c3a27
Mime-Version: 1.0
Message-ID: <92b17af4-bed5-4014-becd-8eeee2430977@www.fastmail.com>
In-Reply-To: <0eed8cd6-cf23-4eeb-ab3e-a851d0266081@www.fastmail.com>
References: <ae53f008-2c84-4964-9b13-3b9f0d00d505@www.fastmail.com>
 <0eed8cd6-cf23-4eeb-ab3e-a851d0266081@www.fastmail.com>
Date: Sat, 07 May 2022 20:05:32 +0100
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <internals@lists.php.net>
Content-Type: multipart/alternative;
 boundary=fd80572a61934cfdbd3f0b4599fee427
Subject: Re: [PHP-DEV] Possible improvements to the Reflection functionality
From: php@ollie.codes ("Ollie Read")

--fd80572a61934cfdbd3f0b4599fee427
Content-Type: text/plain

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*

--fd80572a61934cfdbd3f0b4599fee427--