Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On 05/08/2020 18:10, David Rodrigues wrote: With error supression remotion (9.0?) it could be used for other new features easily. Just to re-iterate something that I'm pretty sure has been said before: the chance of removing the error suppression operator in PHP 9.0 is approximately zero, and the chance of immediately re-using it is significantly lower. We haven't even begun to design the replacement APIs that would make it unnecessary, e.g. atomic file access. Once those are in place, users need time to migrate to them before we could even start the deprecation and removal process. Opportunities that might, depending on a whole bunch of other factors, come in PHP 10.0 or 11.0 are probably not a strong argument for a syntax option. Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
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
escreveu:
> On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei
> wrote:
>
> > On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown wrote:
> > > On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans 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
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Wed, Aug 5, 2020 at 7:20 AM Benjamin Eberlei wrote:
> On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown wrote:
> > On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans 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
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Wed, 5 Aug 2020 at 13:20, Benjamin Eberlei wrote:
>
> 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.
>
The confusing thing about this argument is that as soon as they have
arguments, attributes will have an ending delimiter _whatever_ syntax we
choose, because nobody has ever proposed removing the parentheses around
the arguments.
Detecting the closing parenthesis requires pairing off any parentheses
inside the argument list, but that's still true of the closing bracket in
@[...]. If we make the closing delimiter some random combination like @#]]
then you _still_ need to parse the arguments, because they could contain a
quoted string with those characters in.
While I'm generally in favour of delimited syntaxes, I'm struggling to see
the difference in value between "parentheses are mandatory even if there
are zero arguments" and "the syntax includes an extra pair of outer
brackets".
With no parameters:
@@Foo()
@(Foo)
@[Foo]
@[Foo]@
With complex parameters:
@@Foo('hello @@ world', (1+2)*3)
@(Foo('hello @@ world', (1+2)*3))
@[Foo('hello @[ world ]', [1,2,3])]
@[Foo('hello @[ world ]@ again', [1,2,3])]@
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, 4 Aug 2020, Pedro Magalhães wrote: > I'd like to reinforce the idea that this RFC (as all RFCs) needs a > Yes/No primary vote which should attain a 2/3 majority to pass. I'll make that clear in the RFC, that was obviously my intention. cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, 4 Aug 2020, Levi Morrison wrote: > > I agree with Theodore's points, including that this is metadata on a > > declaration, not a declaration itself. > > Is this technically true? I haven't peeked at the grammar. I suspect > it is a declaration and not an optional piece of data on a > declaration, like say `public`. IMO this is irrelevant anyway. An attribute isn't just a keyword like public, or int. It is *only* an attribute **because** it preceded by a specific token; this makes it not just a declaration. cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown
wrote:
> On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans 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 a 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.
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.
>
> 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.
> Kind regards,
> Theodore
>
> [1]:
> https://wiki.php.net/rfc/shorter_attribute_syntax#comparison_to_other_languages
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
