Re: [RFC] Attributes v2
| From: | Stephen Reay | Date: | Mon, 09 Mar 2020 16:31:04 +0000 |
| Subject: | Re: [RFC] Attributes v2 | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-108911@lists.php.net to get a copy of this message | ||
> On 9 Mar 2020, at 23:27, Benjamin Eberlei <kontakt@beberlei.de> wrote:
>
>
>
> On Mon, Mar 9, 2020 at 5:18 PM Stephen Reay <php-lists@koalephant.com <nf‡ó{õ`
> W’>Ò�\Pmailto:php-lists@koalephant.com>> wrote:
>
>
> > On 9 Mar 2020, at 21:42, Benjamin Eberlei <kontakt@beberlei.de
> > <mailto:kontakt@beberlei.de>> wrote:
> >
> > Hi all,
> >
> > I want to resurrect Dmitrys Attributes RFC that was rejected for 7.1 in
> > 2016 with a few changes, incorporating feedback from the mailing list back
> > then and from talking to previous no voters.
> >
> > The RFC is at https://wiki.php.net/rfc/attributes_v2
> > <https://wiki.php.net/rfc/attributes_v2>
> >
> > A working patch is at
> > https://github.com/beberlei/php-src/pull/2 <þ|‚pz
Ï$¸ë
> > Rïhttps://github.com/beberlei/php-src/pull/2> though
> > work around the details is still necessary.
> >
> > The RFC contains a section with common criticism and objections to
> > attributes, and I hope to have collected and responded to a good amount
> > already from previous discussions.
> >
> > There is also a fair amount of implementation detail still up for debate,
> > which is noted in "Open Issues". I have pre-committed to one approach, but
> > listed alternatives there. On these issues I am looking for your feedback.
> >
> > greetings
> > Benjamin
>
> Hi Benjamin,
>
> I can’t comment on the feasibility of this RFC or the patch, but I like the approach it takes
> to this ‘problem’. I can already imagine a number of ‘nicer’ ways to achieve similar/same
> results using this, so thanks for taking up the baton!
>
> My one small query/request is about the
>
Reflection*::getAttributes method. Is there a philosophical and/or
> technological reason for why it can only ‘filter’ the attributes by a single given name, rather
> than being variadic and filtering against multiple names (i.e. returning those that match any of the
> given names)? I would imagine many uses (particularly within libraries) would end up wanting to
> retrieve multiple attribute types they’re aware of all at once, no?
>
> The name filtering works when using a common base class or interface, so if a library has a
> class "My\BaseAttribute" and all related attributes extend from it, then in the code you
> can do:
>
> $attributes = $reflectionClass->getAttributes(\My\BaseAttribute::class);
>
> This would return all attributes matching.
>
>
> Cheers
>
>
> Stephen
Ah! I had wondered if that type of filtering would be possible (another benefit of using classes for
the attributes) but I didn’t see it mentioned, and wondered if the intention was to leave it to
userland.
Cheers
Stephen