Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108911
Message-ID: <0EFD45F2-DCB6-43E4-B826-907AB4846A65@koalephant.com>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_AEF9F153-F728-42F5-86D5-ADE4130A6FDC"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Date: Mon, 9 Mar 2020 23:31:04 +0700
In-Reply-To: <CAEPJdu=dwV32bZ8hs8_9GT+qvncOcxFEQdxtuDUpobCW0HFKrQ@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
To: Benjamin Eberlei <kontakt@beberlei.de>
References: <CAEPJdunSr8PkBtSLO8g_JMLzM4cFVnXsQSEMFmu2RN25XT=grw@mail.gmail.com>
 <7BAB0436-03EC-4183-BA5A-5A165DAE806E@koalephant.com>
 <CAEPJdu=dwV32bZ8hs8_9GT+qvncOcxFEQdxtuDUpobCW0HFKrQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Attributes v2
From: php-lists@koalephant.com (Stephen Reay)

--Apple-Mail=_AEF9F153-F728-42F5-86D5-ADE4130A6FDC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 9 Mar 2020, at 23:27, Benjamin Eberlei <kontakt@beberlei.de> wrote:
>=20
>=20
>=20
> On Mon, Mar 9, 2020 at 5:18 PM Stephen Reay <php-lists@koalephant.com =
<mailto:php-lists@koalephant.com>> wrote:
>=20
>=20
> > On 9 Mar 2020, at 21:42, Benjamin Eberlei <kontakt@beberlei.de =
<mailto:kontakt@beberlei.de>> wrote:
> >=20
> > Hi all,
> >=20
> > 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.
> >=20
> > The RFC is at https://wiki.php.net/rfc/attributes_v2 =
<https://wiki.php.net/rfc/attributes_v2>
> >=20
> > A working patch is at https://github.com/beberlei/php-src/pull/2 =
<https://github.com/beberlei/php-src/pull/2> though
> > work around the details is still necessary.
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > greetings
> > Benjamin
>=20
> Hi Benjamin,
>=20
> I can=E2=80=99t comment on the feasibility of this RFC or the patch, =
but I like the approach it takes to this =E2=80=98problem=E2=80=99. I =
can already imagine a number of =E2=80=98nicer=E2=80=99 ways to achieve =
similar/same results using this, so thanks for taking up the baton!
>=20
> My one small query/request is about the `Reflection*::getAttributes` =
method. Is there a philosophical and/or technological reason for why it =
can only =E2=80=98filter=E2=80=99 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=E2=80=99re aware of all at once, no?
>=20
> 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:
>=20
> $attributes =3D =
$reflectionClass->getAttributes(\My\BaseAttribute::class);
>=20
> This would return all attributes matching.
>=20
>=20
> Cheers
>=20
>=20
> Stephen=20


Ah! I had wondered if that type of filtering would be possible (another =
benefit of using classes for the attributes) but I didn=E2=80=99t see it =
mentioned, and wondered if the intention was to leave it to userland.=20

Cheers

Stephen=

--Apple-Mail=_AEF9F153-F728-42F5-86D5-ADE4130A6FDC--