Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108919
MIME-Version: 1.0
References: <CAEPJdunSr8PkBtSLO8g_JMLzM4cFVnXsQSEMFmu2RN25XT=grw@mail.gmail.com>
 <5e6696ab.1c69fb81.eb10c.68c2SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5e6696ab.1c69fb81.eb10c.68c2SMTPIN_ADDED_MISSING@mx.google.com>
Date: Mon, 9 Mar 2020 16:29:23 -0300
Message-ID: <CAEsg9X3MT3E9_JiLjfe1YOTpUJ=fRcE2Wu=tKfCLuJ9ea-4nWQ@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000edc61105a071057a"
Subject: Re: [PHP-DEV] Re: [RFC] Attributes v2
From: david.proweb@gmail.com (David Rodrigues)

--000000000000edc61105a071057a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

As I am not a good expert on parser (not to say that I don't do anything),
could you tell me if I can write a note like that?

<<[space]Annotation()[space]>>
<< MyAnnotation(1, 2, 3) >>

It's just because I think the code is more "breathable". Until the PSR
staff decides how best to write.


Atenciosamente,
David Rodrigues


Em seg., 9 de mar. de 2020 =C3=A0s 16:19, Andrea Faulds <ajf@ajf.me> escrev=
eu:

> Benjamin Eberlei wrote:
> > 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
>
> Hi,
>
> I have concerns about these two statements in the RFC:
>
>  > The name of an attribute is resolved against the currently active
> namespace import scope during compilation. The resolved class names are
> then autoloaded to make sure they exist.
>
>  > Consistent with PHP expressions in general, no validation is
> performed if the provided attribute arguments are fullfilling the
> contract of the attribute class constructor. This would happen only when
> accessing attributes as objects in the Reflection API (below).
>
> These two details are inconsistent with eachother: use of an annotation
> triggers an autoload, yet we aren't using the class that is autoloaded
> to validate it? This seems quite wasteful: if we have loaded the class,
> we might as well use it to check the arguments are correct. Also, why
> are we privileging the class existing over the arguments to the class
> being correct? If the arguments can be validated at Reflection time,
> surely the autoloading can be done then too? Both types of coding
> mistake are important.
>
> It also seems inconsistent with existing PHP behaviour, I think normally
> mentioning a class either triggers an immediate autoload and actual
> execution/validation (`new`) or it doesn't (a type declaration). This
> proposal is a strange half-way house.
>
> Is this being done to avoid paying the cost of creating the object at
> compilation time? Because I think triggering the autoload is going to be
> expensive anyway, possibly moreso.
>
> On a different note, the wording here is syntactically ambiguous. It can
> be read as both "if the provided attribute arguments are fullfilling the
> contract [=E2=80=A6], then no validation is performed" and "no validation=
 is
> performed as to whether the provided attribute arguments are fullfilling
> the contract". I read it as the former the first time, which confused me
> for a moment.
>
> Another thing:
>
>  > Thanks to class name resolving, IDEs or static analysis tools can
> perform this validation for the developer.
>
> Is this referencing the autoloading behaviour? I don't see why that
> would be required. (You could also be referring to the fact you use
> classes, which IDEs can look for, instead of arbitrary string
> attributes, which IDEs can not, which does make sense.)
>
> Thanks,
> Andrea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--000000000000edc61105a071057a--