Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111344
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CAEPJdu=9veECGqaUDwHqHWRWk0m0qrzGLs6fnmBa9D5OY6wMqQ@mail.gmail.com> <BYAPR05MB6535960204EC6C755AFA83BADE4B0@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB6535960204EC6C755AFA83BADE4B0@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Wed, 5 Aug 2020 14:10:08 -0300
Message-ID: <CAEsg9X1oDwVz1=D1EtTo_w7Cp_NWPpwry5OViY8i7_Kwvg0_6g@mail.gmail.com>
To: Theodore Brown <theodorejb@outlook.com>
Cc: Benjamin Eberlei <kontakt@beberlei.de>, Derick Rethans <derick@php.net>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000062644e05ac247299"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: david.proweb@gmail.com (David Rodrigues)

--00000000000062644e05ac247299
Content-Type: text/plain; charset="UTF-8"

A new suggestion: @attr(...). It could be used on future for other syntaxes
and should be supersedes the error supression. So will be a BC exclusively
for @attr() error supression for attr() function. But it is few verbose and
easy to understand. With error supression remotion (9.0?) it could be used
for other new features easily.

Em qua, 5 de ago de 2020 13:46, Theodore Brown <theodorejb@outlook.com>
escreveu:

> On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei <kontakt@beberlei.de>
> wrote:
>
> > On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown wrote:
> > > On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans <derick@php.net> wrote:
> > >
> > > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> > > > Syntax Change RFC to reflect that process:
> > > >
> > > > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> > > >
> > > > Patches and comments welcome.
> > >
> > > Hi Derick,
> > >
> > > I don't agree with the main argument put forward in this RFC:
> > >
> > > > The main concern is that @@ has no ending symbol and it's
> > > > inconsistent with the language that it would be the only
> > > > declaration or statement in the whole language that has no ending
> > > > termination symbol.
> > >
> > > Attributes are not a standalone statement or declaration; they are
> > > metadata *on* a declaration. They cannot stand alone, but always
> > > modify the following declaration, just as public and static modify
> > > a method, or a type declaration modifies a parameter or property.
> > >
> > > Modifying declarations (e.g. for visibility and type) do not have an
> > > ending symbol. For example, we don't write something like:
> > >
> > >     [public] function foo([int] $bar) {}
> > >
> > > With the @@ syntax attributes are treated consistently with type and
> > > visibility declarations:
> > >
> > >     @@Jit
> > >     public function foo(@@Deprecated int $bar) {}
> > >
> > > So there is nothing inconsistent about not having a termination
> > > symbol - this is in harmony with visibility and type declarations in
> > > PHP, as well as the attribute syntax used by a majority of C family
> > > languages. [1]
> >
> > Attributes are potentially way more complex than a visibility keyword.
> > As such it is a reasonable requirement to say they should have a
> > unified ending symbol, or more broadly speaking that attributes should
> > be enclosed by syntax.
>
> Hi Benjamin,
>
> Yes, attributes that take arguments are more complex than a
> visibility keyword. Union types can also be more complex.
> Nevertheless it is consistent for these declaration modifiers to
> not have an ending symbol.
>
> > It looks nice for a simple attribute like @@Jit, or for a one without
> > arguments like the used @@Deprecated, but as soon as there are more
> > than one, and they each get arguments, enclosing them has its own
> > benefits over them just standing for themselves.
>
> Can you clarify what benefits there are to enclosing them as soon as
> there is more than one attribute with arguments? From my perspective
> this just adds needless complexity without being more concise than
> the @@ syntax.
>
> To me it also looks somewhat strange and less readable to require
> both a closing parenthesis and a closing bracket when an attribute
> has arguments:
>
>     #[MyAttr(
>         "some value",
>         [1, 2, 3],
>         namedArg: true,
>     )]
>
>     # vs.
>
>     @@MyAttr(
>         "some value",
>         [1, 2, 3],
>         namedArg: true,
>     )
>
> > > When it comes to supporting attribute grouping, I actually consider
> > > this a downside of the #[], @[], and <<>> syntaxes. It complicates
> > > the internal implementation, and makes it so developers have to
> > > choose between two different syntaxes when adding more than one
> > > attribute. In real-world use cases the @@ syntax is just as or even
> > > more concise without the extra parser/compiler complexity:
> > >
> > >     #[Attr1, Attr2] # 15 chars
> > >
> > >     @@Attr1 @@Attr2 # 15 chars
> > >
> > >     # 4 lines, 53 chars not counting whitespace
> > >     @[
> > >         AttrWithParam("foobar"),
> > >         SomeOtherAttr("fizzbuzz"),
> > >     ]
> > >
> > >     # 2 lines, 52 chars
> > >     @@AttrWithParam("foobar")
> > >     @@SomeOtherAttr("fizzbuzz")
> > >
> > > I agree that we want the best syntax, not necessarily the best
> > > **looking** syntax. I still believe that the @@ syntax offers the best
> > > balance here. It's familiar, concise without additional complexity,
> > > and doesn't break useful syntax the way @[] and #[] do.
> >
> > Yes, we have been doing this for 20 years, adding annotations enclosed
> > with /** and */ with each enclosing on its own line for the most part.
> > We even added stars in front of every inbetween line.
> >
> > we are stepping into unchartered territory here with @@ by our
> > standards as PHP community. Using "C familiy" as an argument that
> > they made @ work does not mean much, because the language itself is
> > just the "interface" to the implementation, each C family language
> > probably has vastly different parsers, concerns and approaches. It
> > should be right for PHP.
>
> I agree that we should pick the syntax that is right for PHP. But how
> are the #[] and @[] alternatives a better fit for the language than
> @@, given that they break useful syntax, while @@ isn't useful for
> anything?
>
> It seems like on the one hand the RFC is arguing that @@ is worse
> because that exact token isn't used by another language, and on the
> other hand it is simultaneously being argued that we need to
> implement a more verbose syntax for adding vague complexity in
> the future that isn't used by any other language. Which is it?
>
> A less vague potential extension is attribute nesting, and @@ is
> arguably the best fit for this - one of the motivations for proposing
> it was to allow attribute nesting while preserving readable code and
> a simple internal implementation.
>
> Best regards,
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

--00000000000062644e05ac247299--