Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Interface for reflection entities who implements getAttributes method »

Interface for reflection entities who implements getAttributes method

php.internals

DANIEL VARGAS MUCCILLO

4 years ago
Hi Internals, hope you are all well. I've been playing around with Attributes and found that the only way for safely type hint for reflection entities who implement the getAttributes method is the following union: ReflectionClass|ReflectionClassConstant|ReflectionFunctionAbstract|ReflectionParameter|ReflectionProperty
> $reflectionEntity
For a single use case this was ok, but i would like to survey if people here would be interested in the introduction of a interface against which we could correctly ensure, with less effort, that getAttribute is available. I believe that it would be something along the lines of:
> interface AttributeReflector {
public function getAttributes(?string $name = null, int $flags = 0):
> array;
} I have no experience with the PHP's source code, but if you think that it's a good idea I would like to propose an RFC along with a PoC patch to make this adition. Thanks for your time until now and all the good work I've seen here.
-- Daniel Vargas Muccillo

Larry Garfield

4 years ago
On Fri, Feb 25, 2022, at 4:57 PM, DANIEL VARGAS MUCCILLO wrote:
> Hi Internals, hope you are all well. > > I've been playing around with Attributes and found that the only > way for safely type hint for reflection entities who implement the > getAttributes method is the following union: > > ReflectionClass|ReflectionClassConstant|ReflectionFunctionAbstract|ReflectionParameter|ReflectionProperty >> $reflectionEntity > > > For a single use case this was ok, but i would like to survey if > people here would be interested in the introduction of a interface > against which we could correctly ensure, with less effort, that > getAttribute is available. > > I believe that it would be something along the lines of: > >> interface AttributeReflector { > > public function getAttributes(?string $name = null, int $flags = 0): >> array; > > } > > > I have no experience with the PHP's source code, but if you think > that it's a good idea I would like to propose an RFC along with a PoC > patch to make this adition. > > Thanks for your time until now and all the good work I've seen here. > > -- > Daniel Vargas Muccillo
I've run into this problem as well. I *think* all Reflector children support attributes, so it may not need a separate interface. 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. I have zero availability until mid-March, but I'm open to helping at that point. --Larry Garfield

DANIEL VARGAS MUCCILLO

4 years ago
> > 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 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!
-- Daniel Vargas Muccillo

Larry Garfield

4 years ago
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

DANIEL VARGAS MUCCILLO

4 years ago
> > 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 às 00:35, Larry Garfield <larry@garfieldtech.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 (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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
-- Daniel Vargas Muccillo

Andreas Hennings

4 years ago
On Tue, 1 Mar 2022 at 21:03, DANIEL VARGAS MUCCILLO <daniel.muccillo@ufsm.br> 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.
There is also ReflectionAttribute itself which does not have getAttributes().

Andreas Hennings

4 years ago
Hello list. Another potential benefit of such interfaces can be polyfills. PHP 8.x: class ReflectionClass implements Reflector, AttributesHaving {..} PHP 7.x. class UserlandReflectionClass extends ReflectionClass implements AttributesHaving {..} function f(AttributesHaving $reflector) { $attributes = $reflector->getAttributes(); ... } I wonder if it should be called "AttributeReflector" or "AttributesHaving" or "AbleToHaveAttributesBeing" :) On Fri, 25 Feb 2022 at 23:58, DANIEL VARGAS MUCCILLO <daniel.muccillo@ufsm.br> wrote: