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 <theodor...@outlook.com> escreveu: > On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei <kont...@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 <der...@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 > >
