Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117243
MIME-Version: 1.0
References: <CA+_wxSRxVKoPEJbiV4OPuMufm3brT-ueQdvxEFLKSdTMjBa-Jg@mail.gmail.com>
 <f45c3b9f-6973-4ecb-99c7-1129fa9d51c2@www.fastmail.com> <CA+_wxSTejQ7o5+KXb5uOyb7aNpfxNu==K7YMXGE+Uv4eSV0npA@mail.gmail.com>
 <4c3537fd-5d55-4485-a115-b417950a82b9@www.fastmail.com>
In-Reply-To: <4c3537fd-5d55-4485-a115-b417950a82b9@www.fastmail.com>
Date: Thu, 3 Mar 2022 15:03:00 -0300
Message-ID: <CA+_wxSR7iTb5cbr3sU_AsQx7W96=SUS3_jgox11JA8RsPf-TNw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000013dfcf05d95436d8"
Subject: Re: [PHP-DEV] Interface for reflection entities who implements
 getAttributes method
From: daniel.muccillo@ufsm.br (DANIEL VARGAS MUCCILLO)

--00000000000013dfcf05d95436d8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> 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.


Sounds good to me. I'll work on something along those lines and

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.
>

get in touch with you sometime after mid of this month!

Em qua., 2 de mar. de 2022 =C3=A0s 00:35, Larry Garfield <larry@garfieldtec=
h.com>
escreveu:

> 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 (no=
t
> >    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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--=20
Daniel Vargas Muccillo

--00000000000013dfcf05d95436d8--