Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109634
User-Agent: Cyrus-JMAP/3.1.7-1130-gd0f8b30-fmstable-20200414v1
Mime-Version: 1.0
Message-ID: <16620f3a-1eb6-437e-aa6f-05e5be2aa713@www.fastmail.com>
In-Reply-To: 
 <CAEPJdumF8GaAqLj+=gNi-dMP1GYSvk_DYJuy3gG0N5J1vSXRqQ@mail.gmail.com>
References: 
 <CAEPJdunSr8PkBtSLO8g_JMLzM4cFVnXsQSEMFmu2RN25XT=grw@mail.gmail.com>
 <CAEPJdumF8GaAqLj+=gNi-dMP1GYSvk_DYJuy3gG0N5J1vSXRqQ@mail.gmail.com>
Date: Tue, 14 Apr 2020 10:23:19 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Re: [RFC] Attributes v2
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Apr 14, 2020, at 6:00 AM, Benjamin Eberlei wrote:
> Hi everyone,
>=20
> I have updated the RFC with much of the feedback received here, on Twi=
tter
> and Reddit.
>=20
> https://wiki.php.net/rfc/attributes_v2
>=20
> The following changes were made:
>=20
>    - Changed to support the same attribute multiple times on the same
>    declaration
>    - Added support for attributes on method and function parameters
>    - Replaced *PhpAttribute* interface with an attribute instead
>    - Distinction between userland and compiler attributes and descript=
ion
>    when each of them gets evaluated/validated
>    - Reduce number of examples to shorten RFC a bit and expand the oth=
er
>    examples instead
>    - Introduced validation of compiler attributes at compile time usin=
g a C
>    callback
>    - Offer alternative syntax =E2=80=9C@:=E2=80=9D using new token T_A=
TTRIBUTE which will
>    be included with a secondary vote
>=20
> You may have seen me mentioning that I don't want to deviate from the =
<<>>
> syntax, a topic of heated debate. As Martin helped me tremendously wit=
h the
> RFC and patches he earned to propose an alternative (including patch w=
ith
> prototype). So we will have a secondary vote on syntax being either
> <<Attribute>> or @:Attribute.
>=20
> Let us know what you think about the changes.
>=20
> greetings
> Benjamin

This looks lovely and I look forward to being able to use it!

Questions:

1. Why is exact-match the default for getAttributes(), and "instanceof" =
an extra flag?  I would expect it to the other way around.  The whole po=
int of LSP is that any subclass is a viable replacement for its parent; =
if not, You're Doing It Wrong(tm).  It also means that requesting by int=
erface mandates adding the second parameter or else it will always retur=
n nothing.  What is the reason for not making instanceof the default mat=
ch and offering an EXACT opt-in mode?

2. Regarding sub-annotations, can you still do classes as parameters eve=
n if not as an annotation marker?  Eg:

<<Foo(1, "B", Bar('blah'))>>
function foo()

Or is that also a no-go?

3. I see the most common case for attributes being getting the object ve=
rsion.  With the reflection API as currently described, I see two shortc=
omings.

A) I can't tell if an attribute has a valid object or not before trying =
to access it, which would presumably fail spectacularly.  I believe we n=
eed a way to know if getObject() is going to return a valid value before=
 trying to call it.  I think this is a hard-requirement.

B) Related, as is getting all attributes as objects looks to be rather c=
lunky. =20

$attribute_objectgs =3D array_filter(array_map(function(ReflectionAttrib=
ute $r) {
  if ($r->getObject()) { // Needs something better here.
    return $r->getObject();
  }
}, $obj->getAttributes()));

That's gross. :-)  Can "get all the attributes that can be formed into o=
bjects" be its own operation?  $obj->getAttributeObjects() or some such,=
 that skips over non-instantiable attributes and instantiates the rest?

This isn't a requirement, but without it I predict virtually everyone us=
ing attributes is going to have to recreate the knot of code above.

Thanks again!

--Larry Garfield