Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117186
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4778-g14fba9972e-fm-20220217.001-g14fba997
Mime-Version: 1.0
Message-ID: <4c3537fd-5d55-4485-a115-b417950a82b9@www.fastmail.com>
In-Reply-To: 
 <CA+_wxSTejQ7o5+KXb5uOyb7aNpfxNu==K7YMXGE+Uv4eSV0npA@mail.gmail.com>
References: 
 <CA+_wxSRxVKoPEJbiV4OPuMufm3brT-ueQdvxEFLKSdTMjBa-Jg@mail.gmail.com>
 <f45c3b9f-6973-4ecb-99c7-1129fa9d51c2@www.fastmail.com>
 <CA+_wxSTejQ7o5+KXb5uOyb7aNpfxNu==K7YMXGE+Uv4eSV0npA@mail.gmail.com>
Date: Tue, 01 Mar 2022 21:35:05 -0600
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Interface for reflection entities who implements getAttributes
 method
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Mar 1, 2022, at 2:02 PM, DANIEL VARGAS MUCCILLO wrote:
>>
>>  I *think* all Reflector children support attributes, so it may not need a
>> separate interface.
>
>
> ReflectionZendExtension and ReflectionExtension are currently the only ones
> who implement Reflector but don't support attributes.
>
>
>> However, the entire Reflection class hierarchy is a mess and needs a
>> number of additional interfaces added to it generally.  It makes sense to
>> overhaul it holistically to make sure it all fits together.
>>
>
> Was not aware of other cases, but a quick look led to:
>
>    - getExecutingFile() : string and getExecutingLine() : int in
>    ReflectionFiber and ReflectionGenerator;
>    - getDocComment() : string|false in ReflectionClass,
>    ReflectionClassConstant, ReflectionFunctionAbastract and ReflectionProperty;
>    - getName(), getNameSpaceName() and getModifiers() in some cases (not
>    always together).
>
> Should it be the case to expand the scope to handle these in the same
> proposal or maybe create a Meta RFC and discuss each on their own?

I have been considering a "clean up reflection's class hierarchy" RFC myself; things like getName() are also ubiquitous, but AFAICT is not actually in a common type definition anywhere.

I think a single RFC to clean up all the bits is probably the place to start.  If any particular part of it ends up being controversial we can consider splitting it off then.

>> I have zero availability until mid-March, but I'm open to helping at that
>> point.
>
>
> Thanks for your return on that, I'll try to run at least a little on my own
> foot until there, so I can be less of a burden!

Shoot me an email off list sometime in March as a reminder and let's see what we can figure out. :-)  Or stop by the room 11 chat room.

--Larry Garfield