Interface for reflection entities who implements getAttributes method

2 years ago by DANIEL VARGAS MUCCILLO — view source

unread

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

2 years ago by Larry Garfield — view source

unread

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

2 years ago by DANIEL VARGAS MUCCILLO — view source

unread

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

2 years ago by Larry Garfield — view source

unread

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

2 years ago by DANIEL VARGAS MUCCILLO — view source

unread

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:

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

--

To unsubscribe, visit: https://www.php.net/unsub.php

--
Daniel Vargas Muccillo

2 years ago by Andreas Hennings — view source

unread

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().

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

2 years ago by Andreas Hennings — view source

unread

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:

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