Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108924
MIME-Version: 1.0
References: <CAEPJdunSr8PkBtSLO8g_JMLzM4cFVnXsQSEMFmu2RN25XT=grw@mail.gmail.com>
 <5e6696ab.1c69fb81.eb10c.68c2SMTPIN_ADDED_MISSING@mx.google.com> <CAEsg9X3MT3E9_JiLjfe1YOTpUJ=fRcE2Wu=tKfCLuJ9ea-4nWQ@mail.gmail.com>
In-Reply-To: <CAEsg9X3MT3E9_JiLjfe1YOTpUJ=fRcE2Wu=tKfCLuJ9ea-4nWQ@mail.gmail.com>
Date: Mon, 9 Mar 2020 21:30:40 +0100
Message-ID: <CAEPJdukMYEEsGbXXS9X5JFG9GS9+CzYCfU3eN1_G-2y6E7V3iA@mail.gmail.com>
To: David Rodrigues <david.proweb@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000000f662605a071e16f"
Subject: Re: [PHP-DEV] Re: [RFC] Attributes v2
From: kontakt@beberlei.de (Benjamin Eberlei)

--0000000000000f662605a071e16f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 9, 2020 at 8:30 PM David Rodrigues <david.proweb@gmail.com>
wrote:

> 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.
>

Yes, you can add as many spaces as you want between << Attr >>

On your other question: It is named Attributes in C#, C++, Rust and Hack,
so this name is not something novell. The naming discussion is a coin flip
issue in my opinion. You can't really argue to name it Annotations, just
because Doctrine uses it this way, because historically it would have been
docblock "tags" how php-doc named them.

>
>
> Atenciosamente,
> David Rodrigues
>
>
> Em seg., 9 de mar. de 2020 =C3=A0s 16:19, Andrea Faulds <ajf@ajf.me> escr=
eveu:
>
> > 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 whe=
n
> > 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 normall=
y
> > 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 b=
e
> > expensive anyway, possibly moreso.
> >
> > On a different note, the wording here is syntactically ambiguous. It ca=
n
> > be read as both "if the provided attribute arguments are fullfilling th=
e
> > contract [=E2=80=A6], then no validation is performed" and "no validati=
on is
> > performed as to whether the provided attribute arguments are fullfillin=
g
> > the contract". I read it as the former the first time, which confused m=
e
> > 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
> >
> >
>

--0000000000000f662605a071e16f--