Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Hi Andreas,
On 19/08/2020 11:01, Andreas Leathley wrote:
> I mentioned the benefits of @{} in an email to this list on Monday, with
> the proposal to have both @@ and @{} as attribute syntax, so both camps
> could have their syntax (one with delimiters, one without) with minimal
Please, one and only syntax would be plenty. We have history showing
that having two was not a brilliant idea, i.e. string offsets.
> But I guess the division about syntax is too big at this point to
> consider an approach where we just offer both types of syntax. From a
> PHP developer viewpoint, it would be preferable though.
To each their own. From my viewpoint, and possibly quite a few other's,
having two syntaxes is not preferable.
Cheers
--
Matteo Beccati
Development & Consulting - http://www.beccati.com/
--
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 Wed, 19 Aug 2020 at 09:46, Jordi Boggiano wrote: > Just to mention something here in a bit more depth because it is easy to > overlook in the RFC if you have looked at it a lot. > > In "Potential Future Benefits of Enclosed Delimiter Syntax" there is an > addition of an example using an attribute for an AOP-style > before-function callback: > > @:Before(fn ($x) => $x*4) > > IMO this is much more readable and self-documenting than a dangling > lambda like @[fn ($x) => %x*4], as the attribute name hints at what is > going on, and it provides enclosure with the arg list (). > I read a lot of code I didn't write, and I like your example. It is much more readable and self-documenting. Peter
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On 19.08.20 11:12, Benjamin Eberlei wrote:
With the choice being @@ or @{} - nothing would stop someone (not me ;-))
to make an RFC for 8.1 or later proposing to add a second syntax.
Sure. If @@ would end up winning again (who knows at this point), at
least one positive thing is that @{} could be added later without having
a BC break, which reduces the potential future benefits of an enclosed
syntax, as it is still possible if needed.
--
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 Wed, Aug 19, 2020 at 11:13 AM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> Please add discussion about merge conflicts. Any inline grouped
> attribute syntax needs a manual conflict resolution.
>
> With ungrouped syntax, I expect recommended CS to be one attribute per
> line.
>
This is discussed under grouping already. It is a coding style issue, so
it's not really relevant as you can use all the syntaxes in an ungrouped
mode if you are concerned about conflicts.
> If this should be the case also for grouped syntax, then it not +1
> character, but +2 new lines per every annotated element.
>
> Also, is 2/3 majority required by RFC rules satisfied by the "Are you
> okay with re-voting on the attribute syntax for PHP 8.0, again?"
> question?
> I think we should require 2/3 votes at least on the question if we
> should allow grouping or not and if accepted, use STV results on the
> prefered prefix symbols/syntax.
>
Yes, that was exactly the same type of vote for "shorter attribute syntax"
RFC.
>
> With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>
> Michael Voříšek
>
> On 19 Aug 2020 10:47, Benjamin Eberlei wrote:
>
> > On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei
> > wrote:
> >
> > On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
> >
> > Hi,
> >
> > Out of Banjamin's suggestion[1 [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.
> >
> > FWIW, this has an excemption from the RM Sara as per [2 [2]]:
> >
> > * Shorter Attribute Syntax Change
> > - Joe/Derick - Please make sure this RFC moves along and reaches
> > conclusion by beta3, as discussed previously.
> > Heads up: This RFC is now going to vote tomorrow:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> I have updated the RFC one last time with as much of the feedback as
> possible:
>
> - a section about comparing to complexity of type definitions
> - removal of the machine reading section as too narrow and ultimately
> not
> that important as downstream libraries just have to deal with any of it
> - some more nuances in forward compatibility pro/cons section of #[]
> - smaller corrections and improvements.
>
> I don't think something major is missing now.
>
> One last change that I didn't see yesterday as it was on Github and not
> this list is the addition of another syntax proposal @{} with the same
> benefits as @[], a little more snowflake than compared to other
> languages,
> but without the BC Break.
>
> >> cheers,
> >> Derick
> >>
> >> [1] https://externals.io/message/111218#111261
> >> [2] https://externals.io/message/111286#111286
> >>
> >> --
> >> 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
>
>
> Links:
> --
> [1] https://externals.io/message/111218#111261
> [2] https://externals.io/message/111286#111286
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Wed, Aug 19, 2020 at 11:01 AM Andreas Leathley
wrote:
> On 19.08.20 10:47, Benjamin Eberlei wrote:
> > One last change that I didn't see yesterday as it was on Github and not
> > this list is the addition of another syntax proposal @{} with the same
> > benefits as @[], a little more snowflake than compared to other
> languages,
> > but without the BC Break.
>
> I mentioned the benefits of @{} in an email to this list on Monday, with
> the proposal to have both @@ and @{} as attribute syntax, so both camps
> could have their syntax (one with delimiters, one without) with minimal
> BC breaks, and leave the decision to the PHP developers/projects what
> they prefer in what circumstances, because there can be valid reasons to
> use both - I probably would use both. @{} could be good to define
> multiple attributes for classes/properties, @@ could be good for short
> attributes or ones very entrenched within the code, like function
> parameters. The @{} syntax could be amended in the future, so this would
> also be "future-proof".
>
> But I guess the division about syntax is too big at this point to
> consider an approach where we just offer both types of syntax. From a
> PHP developer viewpoint, it would be preferable though.
>
The "problem" with having both @@ and @{} would be that we would need two
new tokens instead of one.
We have a bunch of proposals that would support both grouped and ungrouped
with the same syntax, so a solution that ends up ending two new tokens and
syntaxes would be less preferable.
With the choice being @@ or @{} - nothing would stop someone (not me ;-))
to make an RFC for 8.1 or later proposing to add a second syntax.
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Please add discussion about merge conflicts. Any inline grouped
attribute syntax needs a manual conflict resolution.
With ungrouped syntax, I expect recommended CS to be one attribute per
line.
If this should be the case also for grouped syntax, then it not +1
character, but +2 new lines per every annotated element.
Also, is 2/3 majority required by RFC rules satisfied by the "Are you
okay with re-voting on the attribute syntax for PHP 8.0, again?"
question?
I think we should require 2/3 votes at least on the question if we
should allow grouping or not and if accepted, use STV results on the
prefered prefix symbols/syntax.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 19 Aug 2020 10:47, Benjamin Eberlei wrote:
On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei
wrote:
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
Hi,
Out of Banjamin's suggestion[1 [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.
FWIW, this has an excemption from the RM Sara as per [2 [2]]:
* Shorter Attribute Syntax Change
- Joe/Derick - Please make sure this RFC moves along and reaches
conclusion by beta3, as discussed previously.
Heads up: This RFC is now going to vote tomorrow:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
I have updated the RFC one last time with as much of the feedback as
possible:
- a section about comparing to complexity of type definitions
- removal of the machine reading section as too narrow and ultimately
not
that important as downstream libraries just have to deal with any of it
- some more nuances in forward compatibility pro/cons section of #[]
- smaller corrections and improvements.
I don't think something major is missing now.
One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other
languages,
but without the BC Break.
cheers,
Derick
[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286
--
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
Links:
--
[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On 19.08.20 10:47, Benjamin Eberlei wrote:
One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other languages,
but without the BC Break.
I mentioned the benefits of @{} in an email to this list on Monday, with
the proposal to have both @@ and @{} as attribute syntax, so both camps
could have their syntax (one with delimiters, one without) with minimal
BC breaks, and leave the decision to the PHP developers/projects what
they prefer in what circumstances, because there can be valid reasons to
use both - I probably would use both. @{} could be good to define
multiple attributes for classes/properties, @@ could be good for short
attributes or ones very entrenched within the code, like function
parameters. The @{} syntax could be amended in the future, so this would
also be "future-proof".
But I guess the division about syntax is too big at this point to
consider an approach where we just offer both types of syntax. From a
PHP developer viewpoint, it would be preferable though.
--
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 18, 2020 at 8:00 PM Benjamin Eberlei
wrote:
>
>
> On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
>
>> Hi,
>>
>> 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.
>>
>> FWIW, this has an excemption from the RM Sara as per [2]:
>>
>> > * Shorter Attribute Syntax Change
>> >- Joe/Derick - Please make sure this RFC moves along and reaches
>> > conclusion by beta3, as discussed previously.
>>
>> Heads up: This RFC is now going to vote tomorrow:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> I have updated the RFC one last time with as much of the feedback as
> possible:
>
> - a section about comparing to complexity of type definitions
> - removal of the machine reading section as too narrow and ultimately not
> that important as downstream libraries just have to deal with any of it
> - some more nuances in forward compatibility pro/cons section of #[]
> - smaller corrections and improvements.
>
> I don't think something major is missing now.
>
One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other languages,
but without the BC Break.
>
>
>>
>> cheers,
>> Derick
>>
>> [1] https://externals.io/message/111218#111261
>> [2] https://externals.io/message/111286#111286
>>
>> --
>> 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
Hi, On 18/08/2020 20:00, Benjamin Eberlei wrote: https://wiki.php.net/rfc/shorter_attribute_syntax_change I have updated the RFC one last time with as much of the feedback as possible: - a section about comparing to complexity of type definitions - removal of the machine reading section as too narrow and ultimately not that important as downstream libraries just have to deal with any of it - some more nuances in forward compatibility pro/cons section of #[] - smaller corrections and improvements. I don't think something major is missing now. Thanks for the updates Benjamin. Just to mention something here in a bit more depth because it is easy to overlook in the RFC if you have looked at it a lot. In "Potential Future Benefits of Enclosed Delimiter Syntax" there is an addition of an example using an attribute for an AOP-style before-function callback: @:Before(fn ($x) => $x*4) IMO this is much more readable and self-documenting than a dangling lambda like @[fn ($x) => %x*4], as the attribute name hints at what is going on, and it provides enclosure with the arg list (). I hope this will address the worries that the shorter @@/@: syntaxes would prevent us from adding some features later based on a lack of end delimiter, as it was the only objective technical argument in favor of #[]/@[]. Now it's IMO all about what syntax people prefer visually.. Best, Jordi -- Jordi Boggiano @seldaek - https://seld.be -- 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 Wed, Aug 19, 2020 at 12:03 AM Theodore Brown
wrote:
> On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei
> wrote:
>
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > I have updated the RFC one last time with as much of the feedback
> > as possible:
> >
> > - a section about comparing to complexity of type definitions
> > - removal of the machine reading section as too narrow and
> > ultimately not that important as downstream libraries just have to
> > deal with any of it
> > - some more nuances in forward compatibility pro/cons section of #[]
> > - smaller corrections and improvements.
> >
> > I don't think something major is missing now.
>
> Hi Benjamin,
>
> Thanks for the updates. I just have a few more thoughts on aspects
> that haven't been mentioned before:
>
> 1. The **Attributes are not like Modifiers** section makes an
>argument that having an end delimiter "groups docblock comment and
>attributes into two similarly shaped syntax blocks that prefix the
>declaration increasing familiarity."
>
> In my own (admittedly subjective) opinion, an end delimiter on
> attributes actually increases confusion when there is also a
> docblock. To reuse the example from the RFC:
>
> /**
> * A comment describing things.
> *
> * @psalm-suppress SomeRule
> */
> #[
> ORM\Entity(),
> ORM\Table("baz")
> ]
> final class Something {
> }
>
> Because the attribute group has its own start and end delimiters, it
> almost looks like the doc comment applies to the attribute block
> rather than the class.
>
> With the `@@` or `@:` syntax, it seems clearer that attributes are
> part of the class/function/property declaration, rather than their
> own standalone construct which docblocks can be applied to:
>
> /**
> * A comment describing things.
> *
> * @psalm-suppress SomeRule
> */
> @@ORM\Entity
> @@ORM\Table("baz")
> final class Something {
> }
>
>
> Given that the only complex part of an attribute is the optional
> argument list, which already has its own start/end delimiters, I
> ultimately don't find the "complexity" argument very compelling for
> needing an additional attribute end delimiter besides.
>
>
> 2. In the **Discussion on grep'ability** section, the RFC says
>"Enforcement of same line is also not the case for other
>declarations that benefit from grep'ability such as classes,
>functions, constants and so on in PHP already, so this is not
>consistent within the language."
>
> This seems to be outdated information, based on Martin's original
> patch before the "Treat namespaced names as single token" RFC was
> accepted. In the current `@@` implementation, there is no single-line
> enforcement, consistent with other parts of the language.
>
Right, i didn't realize this restriction was lifted and updated this
section.
This doesn't change the argument though that when you need coding styles to
enforce a particular style that grepability works, then you can find a
coding standard with all syntaxes that has good grepability, i.e. by not
using grouping.
>
> Not having whitespace between the attribute token and name would be
> enforced by coding style conventions, just as is the case with
> function/class/constant definitions.
>
> Note that there is some precedent in PHP for choosing syntax that
> ensures easier searching (for example, the decision to place return
> type declarations after the parameter list rather than before the
> function name).
>
> Grep'ability isn't a big deal when finding usages in an IDE, but
> sometimes there is a need to search code on a server or other source
> without an IDE, in which case easy grep'ability can be very helpful.
>
> Sincerely,
> Theodore
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei wrote:
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> I have updated the RFC one last time with as much of the feedback
> as possible:
>
> - a section about comparing to complexity of type definitions
> - removal of the machine reading section as too narrow and
> ultimately not that important as downstream libraries just have to
> deal with any of it
> - some more nuances in forward compatibility pro/cons section of #[]
> - smaller corrections and improvements.
>
> I don't think something major is missing now.
Hi Benjamin,
Thanks for the updates. I just have a few more thoughts on aspects
that haven't been mentioned before:
1. The **Attributes are not like Modifiers** section makes an
argument that having an end delimiter "groups docblock comment and
attributes into two similarly shaped syntax blocks that prefix the
declaration increasing familiarity."
In my own (admittedly subjective) opinion, an end delimiter on
attributes actually increases confusion when there is also a
docblock. To reuse the example from the RFC:
/**
* A comment describing things.
*
* @psalm-suppress SomeRule
*/
#[
ORM\Entity(),
ORM\Table("baz")
]
final class Something {
}
Because the attribute group has its own start and end delimiters, it
almost looks like the doc comment applies to the attribute block
rather than the class.
With the `@@` or `@:` syntax, it seems clearer that attributes are
part of the class/function/property declaration, rather than their
own standalone construct which docblocks can be applied to:
/**
* A comment describing things.
*
* @psalm-suppress SomeRule
*/
@@ORM\Entity
@@ORM\Table("baz")
final class Something {
}
Given that the only complex part of an attribute is the optional
argument list, which already has its own start/end delimiters, I
ultimately don't find the "complexity" argument very compelling for
needing an additional attribute end delimiter besides.
2. In the **Discussion on grep'ability** section, the RFC says
"Enforcement of same line is also not the case for other
declarations that benefit from grep'ability such as classes,
functions, constants and so on in PHP already, so this is not
consistent within the language."
This seems to be outdated information, based on Martin's original
patch before the "Treat namespaced names as single token" RFC was
accepted. In the current `@@` implementation, there is no single-line
enforcement, consistent with other parts of the language.
Not having whitespace between the attribute token and name would be
enforced by coding style conventions, just as is the case with
function/class/constant definitions.
Note that there is some precedent in PHP for choosing syntax that
ensures easier searching (for example, the decision to place return
type declarations after the parameter list rather than before the
function name).
Grep'ability isn't a big deal when finding usages in an IDE, but
sometimes there is a need to search code on a server or other source
without an IDE, in which case easy grep'ability can be very helpful.
Sincerely,
Theodore
--
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 18, 2020 at 12:04 AM Benas IML wrote: > >> >> From the updated RFC: >> >> > There are multiple reasons why we believe the previous vote should be >> > revisited: >> >> Ok, bring it on! >> >> > At the point of the vote for @@, it was not clear that the syntax required >> > the namespace token RFC to be viable. >> > While this is not a problem anymore, the @@ syntax might not have come out >> > on top if this information was known beforehand. >> >> If anything, this is an argument AGAINST this RFC. A "bad" decision >> was taken. The problem with it was fixed. No need to change anything. >> The argument comes across as disingenuous, I'm afraid. > > And then boo-yah, 6 months later we want to implement a cool new feature to > attributes > (a lot of examples were said before, ain't repeating myself) but we can't :(( > because there is no ending delimiter and thus, we will run into parsing > issues. > Don't really understand how that is a response to my argument. However, I understand your opinion, I just find it hard to find convincing evidence in support of it in this RFC. >> >> Moving on... >> >> > The #[] syntax provides the benefit of forward compatibility, but this >> > also introduces some potential problems for PHP 7 code. >> > An alternative syntax @[] was suggested to eleviate these problems which >> > was not previously voted on. >> >> Ok, let's analyze the logic here as well: #[] lost the vote. #[] would >> have had some problems. Are there any > > > What problems? Besides the BC breaks that all of the syntaxes (except > `<<...>>`) have, there are no problems. > I'm just quoting the RFC here, then paraphrasing. If you want to know what "potential problems" #[] introduces for PHP7 code, you'll have to ask the authors of the RFC. >> syntaxes we still haven't voted >> on? Yes! >> Come on... >> >> And lastly... >> >> > We argue why we should strongly favor a syntax with closing delimiter to >> > keep consistency with other parts >> > of the language and propose to use #[], @[], or the original << … >> >> > instead. >> >> This is the only part that contains logically valid arguments, albeit >> most are subjective and speculative. Which is not to say it's not >> worth voting on them. >> But looking for actual facts, I only came across only this little cutie: >> > For VIM users, the % operation to jump between opening and closing part of >> > declaration that would automatically work with [ and ]. >> I fully expect all 3 VIM users to vote in favor of this RFC ;-) >> >> Ok, enough of my sarcasm - I only wish you'd put your strongest >> arguments first and focused on quality over quantity. > > > I wish someone actually gave reasonable arguments as to why `@@` is better. > Because a) no one cares if we have to type 2 or 3 characters b) `@@` does not > ensure 100% safe future c) it does not decrease complexity in any way. > @@ already won the vote. The burden of proof for superseding the popular vote should be on the RFC authors. But for the record, I visually and mentally like all the examples with @@ more than their block-syntax counterparts. As I said previously; without hard facts, it's just a subjective matter. If I'm a weirdo for actually liking @@ I'm not sorry :-D Best, Jakob -- 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 18, 2020, 1:42 AM Andreas Leathley wrote:
> On 18.08.20 00:03, Benas IML wrote:
> > And then boo-yah, 6 months later we want to implement a cool new
> > feature to
> > attributes (a lot of examples were said before, ain't repeating myself)
> but
> > we can't :(( because there is no ending delimiter and thus, we will run
> > into parsing issues.
>
> Both @{} and @@{} would be possible as a future extension of the syntax
> and would have no BC break at all, if extending the syntax is something
> that would/should happen - just as possible suggestions.
Introducing `@@{}` would:
* be against `@@` "conciseness" ideology and would be longer than
`@[]`/`#[]`
* what's the point of creating a new syntax if we can just pick `@[]`/`#[]`?
> It is likely though that the vast majority of attribute usage will be
> quite simple (like the ones we have today with annotations: for routes,
> for validation, for ORMs), so having a simple syntax for a feature which
> is mostly used in a straightforward way does not seem that crazy.
>
"It is likely" is key here. So far, the only "positive" thing I have seen
about `@@` is smaller BC break which is albeit questionable since I was
able to find only 2 instances of a BC break for `@[]` (when searching top
Composer packages).
As for other "pros", let's be honest, no one cares that `@@` is 2
characters whereas `@[]` is 3 characters.
> And about your condescending remark of people trying to add to the
> discussion who have not "proven themselves in the PHP source code":
> Having a discussion with people who have different viewpoints seems like
> a big benefit for any project, because it is impossible to be an expert
>
At the end of the day, the so called "experts" are maintaining PHP source
code.
Having an opinion is okay but being ignorant about the issues which might
arise to the maintainers is completely unacceptable.
at C code, php-src, PHP code, all PHP frameworks, all the PHP libraries,
> and all the ways PHP is used today - yet all that can be relevant for
> language changes and the actual usage of new features, including the
> syntax.
>
Best regards,
Benas
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote: > Hi, > > 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. > > FWIW, this has an excemption from the RM Sara as per [2]: > > > * Shorter Attribute Syntax Change > >- Joe/Derick - Please make sure this RFC moves along and reaches > > conclusion by beta3, as discussed previously. > > Heads up: This RFC is now going to vote tomorrow: https://wiki.php.net/rfc/shorter_attribute_syntax_change I have updated the RFC one last time with as much of the feedback as possible: - a section about comparing to complexity of type definitions - removal of the machine reading section as too narrow and ultimately not that important as downstream libraries just have to deal with any of it - some more nuances in forward compatibility pro/cons section of #[] - smaller corrections and improvements. I don't think something major is missing now. > > cheers, > Derick > > [1] https://externals.io/message/111218#111261 > [2] https://externals.io/message/111286#111286 > > -- > 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
Hi Benjamin, ## Easier machine parsing? The RFC shows a list of different ways that attributes with the `@@` syntax can end, and claims "This makes programmatic token based scanning for attribute syntax without a closing delimiter such as `@@` unnecessarily complicated." But I've worked with userland token stream scanners myself, and it's not difficult to skip `T_WHITESPACE` and `T_COMMENT` tokens. Once you do that, parsing an attribute is as simple as finding any `T_ATTRIBUTE` token followed by the name token, then checking for an optional argument list. If there's not an argument list, that's then end of the attribute, otherwise the end is the end of the argument list. With the `@[]` and `#[]` syntaxes, a userland token parser is actually *more* complex due to grouping. It not only has to do the same things listed above, but it also has to check whether there are multiple comma-separated attributes between the start/end delimiters (making sure not to confuse a comma-separated attribute with a comma-separated argument, or the end of an array argument with the attribute end delimiter). So I don't understand how the RFC can claim that attributes without an end symbol "introduce additional complexity" for machines, when if anything the opposite is true. (And don't get me started about the extra difficulty for token stream scanners with the `<<>>` syntax which has no `T_ATTRIBUTE` token). I noticed you did not answer this point at all, I know there are lots of emails to reply to but IMO this is quite an important dismissal of one of the few technical arguments made for grouping, and also something I tried to hint at on Twitter back on Sunday.. Reading the RFC again now, IMO the whole "Machine Scanning for End of Attribute Declaration" section should be removed. From the points left, only "Potential Future Benefits of Enclosed Delimiter Syntax" is technically valid but really dependent on what we see as interesting future use cases. The rest is rather subjective and thus not really worth discussing, it'll be up to everyone's preference. Best, Jordi -- Jordi Boggiano @seldaek - https://seld.be -- 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 18.08.20 00:03, Benas IML wrote:
And then boo-yah, 6 months later we want to implement a cool new
feature to
attributes (a lot of examples were said before, ain't repeating myself) but
we can't :(( because there is no ending delimiter and thus, we will run
into parsing issues.
Both @{} and @@{} would be possible as a future extension of the syntax
and would have no BC break at all, if extending the syntax is something
that would/should happen - just as possible suggestions.
It is likely though that the vast majority of attribute usage will be
quite simple (like the ones we have today with annotations: for routes,
for validation, for ORMs), so having a simple syntax for a feature which
is mostly used in a straightforward way does not seem that crazy.
And about your condescending remark of people trying to add to the
discussion who have not "proven themselves in the PHP source code":
Having a discussion with people who have different viewpoints seems like
a big benefit for any project, because it is impossible to be an expert
at C code, php-src, PHP code, all PHP frameworks, all the PHP libraries,
and all the ways PHP is used today - yet all that can be relevant for
language changes and the actual usage of new features, including the syntax.
--
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 18, 2020, 12:56 AM Jakob Givoni wrote: > On Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei > wrote: > > > > We have updated the RFC with all (hopefully) of the feedback from this > > discussion: > > > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > > > Most notable changes are: > > - A new section with several subsections on the benefits of a closing > > delimiter / enclosing syntax. > > - A section on grouping pro/cons > > - Inclusion of @: as per Theodores request > > > > We are looking for further feedback from the community. > > > > From the updated RFC: > > > There are multiple reasons why we believe the previous vote should be > revisited: > > Ok, bring it on! > > > At the point of the vote for @@, it was not clear that the syntax > required the namespace token RFC to be viable. > > While this is not a problem anymore, the @@ syntax might not have come > out on top if this information was known beforehand. > > If anything, this is an argument AGAINST this RFC. A "bad" decision > was taken. The problem with it was fixed. No need to change anything. > The argument comes across as disingenuous, I'm afraid. > And then boo-yah, 6 months later we want to implement a cool new feature to attributes (a lot of examples were said before, ain't repeating myself) but we can't :(( because there is no ending delimiter and thus, we will run into parsing issues. > Moving on... > > > The #[] syntax provides the benefit of forward compatibility, but this > also introduces some potential problems for PHP 7 code. > > An alternative syntax @[] was suggested to eleviate these problems which > was not previously voted on. > > Ok, let's analyze the logic here as well: #[] lost the vote. #[] would > have had some problems. Are there any What problems? Besides the BC breaks that all of the syntaxes (except `<<...>>`) have, there are no problems. syntaxes we still haven't voted > on? Yes! > Come on... > > And lastly... > > > We argue why we should strongly favor a syntax with closing delimiter to > keep consistency with other parts > > of the language and propose to use #[], @[], or the original << … >> > instead. > > This is the only part that contains logically valid arguments, albeit > most are subjective and speculative. Which is not to say it's not > worth voting on them. > But looking for actual facts, I only came across only this little cutie: > > For VIM users, the % operation to jump between opening and closing part > of declaration that would automatically work with [ and ]. > I fully expect all 3 VIM users to vote in favor of this RFC ;-) > > Ok, enough of my sarcasm - I only wish you'd put your strongest > arguments first and focused on quality over quantity. > I wish someone actually gave reasonable arguments as to why `@@` is better. Because a) no one cares if we have to type 2 or 3 characters b) `@@` does not ensure 100% safe future c) it does not decrease complexity in any way. > - Jakob > > -- > 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 Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei wrote: > > We have updated the RFC with all (hopefully) of the feedback from this > discussion: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > Most notable changes are: > - A new section with several subsections on the benefits of a closing > delimiter / enclosing syntax. > - A section on grouping pro/cons > - Inclusion of @: as per Theodores request > > We are looking for further feedback from the community. > >From the updated RFC: > There are multiple reasons why we believe the previous vote should be > revisited: Ok, bring it on! > At the point of the vote for @@, it was not clear that the syntax required > the namespace token RFC to be viable. > While this is not a problem anymore, the @@ syntax might not have come out on > top if this information was known beforehand. If anything, this is an argument AGAINST this RFC. A "bad" decision was taken. The problem with it was fixed. No need to change anything. The argument comes across as disingenuous, I'm afraid. Moving on... > The #[] syntax provides the benefit of forward compatibility, but this also > introduces some potential problems for PHP 7 code. > An alternative syntax @[] was suggested to eleviate these problems which was > not previously voted on. Ok, let's analyze the logic here as well: #[] lost the vote. #[] would have had some problems. Are there any syntaxes we still haven't voted on? Yes! Come on... And lastly... > We argue why we should strongly favor a syntax with closing delimiter to keep > consistency with other parts > of the language and propose to use #[], @[], or the original << … >> instead. This is the only part that contains logically valid arguments, albeit most are subjective and speculative. Which is not to say it's not worth voting on them. But looking for actual facts, I only came across only this little cutie: > For VIM users, the % operation to jump between opening and closing part of > declaration that would automatically work with [ and ]. I fully expect all 3 VIM users to vote in favor of this RFC ;-) Ok, enough of my sarcasm - I only wish you'd put your strongest arguments first and focused on quality over quantity. - Jakob -- 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 Mon, Aug 17, 2020 at 10:21 AM Benjamin Eberlei wrote:
> On Mon, Aug 17, 2020 at 5:14 PM Theodore Brown wrote:
> > On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown wrote:
> > > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> > > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown wrote:
> > > > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > > > >
> > > > > The RFC shows an example of a potential "simpler" attribute using a
> > > > > string instead of a class name. I honestly have no idea what this is
> > > > > supposed to do or what benefit it would have over normal attributes.
> > > > >
> > > > > The concept of attributes being a class name with optional arguments
> > > > > has been proven over many years by its use in docblock annotations,
> > > > > and if there was some deficiency in what this syntax allows it seems
> > > > > like we would have discovered it by now.
> > > >
> > > > I agree on just the string, but a closure would make 100% sense for
> > > > a decorating feature. Javascript and Python "Attributes" work as
> > > > decorators, i.e. they get called around the decorated function.
> > > >
> > > > It is not a completely unrealistic feature to think off:
> > > >
> > > > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> > > > function foo($message) {}
> > >
> > > As I understand it JavaScript decorators do not use anonymous
> > > functions for decorators like this, though. Instead you would make a
> > > named function and apply it with `@myFunc()` before the decorated
> > > function or class.
> > >
> > > Presumably we could accomplish the same thing in PHP with e.g. an
> > > `__invoke` method in the attribute class, without complicating the
> > > attribute syntax itself.
> >
> > One other thought on this. I agree that decorators are not a
> > completely unrealistic future feature. However, it must be noted that
> > both JavaScript and Python use the `@Attr` syntax for decorators, and
> > the lack of an end delimiter in no way precludes this usage.
>
> Yes they support decorators with @, but they don't support metadata.
>
> With this syntax its either or, because from @Attr only you cannot
> decide if its a decorator or a metadata attribute.
>
> It would not work by detecting __invoke on the Attribute, because
> the whole architecture of Attributes is based on deferring
> autoloading until Reflection*::getAttributes(). But when you use
> decorators, you would need to know this at runtime, so the
> zend_attribute datastructure would need to know its not an metadata
> attribute, but a decorator.
Hi Benjamin,
That's true. Due to deferred loading we would need some kind of
new syntax to denote checked attributes or decorators, *regardless
of whether the attribute syntax has an end delimiter*. As I've
suggested before, we could potentially denote checked attributes
in the future like this:
@@!Attr("some val")
function foo() {...}
I still believe that using an inline closure attribute syntax like
the example in the RFC would not be a good solution for decorators,
as it reduces reusability and readability, and would prevent applying
a decorator that includes metadata.
Best regards,
Theodore
--
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 Mon, Aug 17, 2020, at 7:30 AM, Michael Voříšek - ČVUT FEL wrote:
> > possibility to keep @@ and add @{} as a second syntax for attributes
>
> +1, but I would keep same prefix, ie. @@{} (or @@[]), for both syntaxes,
> it is much easier for human eyes to search for one thing, also easier
> for grep
>
> On 17 Aug 2020 12:48, Andreas Leathley wrote:
>
> > As a possible addition/discussion point, I only noticed today that @{}
> > is a syntax that has not been mentioned yet, also not in any previous
> > discussions about attributes as far as I can tell. @{} currently leads
> > to a syntax error, so there is no BC break, and {} is common syntax for
> > grouping expressions in PHP, much more so than [], which is an
> > array-specific syntax.
> >
> > Would it be a possibility to keep @@ and add @{} as a second syntax for
> > attributes, that can be used for grouping (for situations where that
> > makes sense) or other possibly future extensions? Then @@ would be a
> > good syntax for simple attribute definitions, and @{} could be an
> > alternative for people who want to group them or if any more complex
> > attribute features are added to the language later.
> >
> > Because both sides of the "ending delimiter or no ending delimiter"
> > discussion do have some points in their favor, and it seems quite
> > individual what each person prefers. For a language it could be
> > beneficial to give some choices to the developer instead of foreseeing
> > each individual use case, and maybe attributes is such a feature.
> >
> > I previously thought about suggesting both types of syntax (with and
> > without delimiters), but felt the current options all have too many side
> > effects to choose "two side effects" or two BC breaks. But the @@ BC
> > break seems the most harmless BC break of the bunch, and @{} does not
> > have a BC break, so these two option might be good together.
Supporting both @@Foo and @@{ Foo } sounds really nice on the surface as a
compromise, but runs into the problem of any 3rd party parsers now needing to
do extra work as well. Minimizing work for 3rd party parsers is one of the
main goals under discussion, as I understand it. I'm not sure it's viable,
therefore, much as it does have its appeal conceptually.
--Larry Garfield
--
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 Mon, Aug 17, 2020 at 5:
14 PM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown
> wrote:
>
> > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei
> wrote:
> > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> wrote:
> > > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > > >
> > > > The RFC shows an example of a potential "simpler" attribute using a
> > > > string instead of a class name. I honestly have no idea what this is
> > > > supposed to do or what benefit it would have over normal attributes.
> > > >
> > > > The concept of attributes being a class name with optional arguments
> > > > has been proven over many years by its use in docblock annotations,
> > > > and if there was some deficiency in what this syntax allows it seems
> > > > like we would have discovered it by now.
> > >
> > > I agree on just the string, but a closure would make 100% sense for
> > > a decorating feature. Javascript and Python "Attributes" work as
> > > decorators, i.e. they get called around the decorated function.
> > >
> > > It is not a completely unrealistic feature to think off:
> > >
> > > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> > > function foo($message) {}
> >
> > As I understand it JavaScript decorators do not use anonymous
> > functions for decorators like this, though. Instead you would make a
> > named function and apply it with `@myFunc()` before the decorated
> > function or class.
> >
> > Presumably we could accomplish the same thing in PHP with e.g. an
> > `__invoke` method in the attribute class, without complicating the
> > attribute syntax itself.
>
> One other thought on this. I agree that decorators are not a
> completely unrealistic future feature. However, it must be noted that
> both JavaScript and Python use the `@Attr` syntax for decorators, and
> the lack of an end delimiter in no way precludes this usage.
>
Yes they support decorators with @, but they don't support metadata.
With this syntax its either or, because from @Attr only you cannot decide
if its a decorator or a metadata attribute.
It would not work by detecting __invoke on the Attribute, because the whole
architecture of Attributes is based on deferring autoloading until
Reflection*::getAttributes().
But when you use decorators, you would need to know this at runtime, so the
zend_attribute datastructure would need to know its not an metadata
attribute,
but a decorator.
> The whole point of a decorator is to offer syntax sugar for a common
> reusable pattern (pass a function/class to another function which can
> add additional information or behavior to it). It's not clear how an
> anonymous closure would be useful for this, since it would not allow
> reusability, which defeats the purpose.
>
> So the argument that an end delimiter has "potential future benefits"
> still lacks any realistic examples, and is countered by years of
> proven usage of the `@Attr` syntax in docblocks and other languages.
>
> Sincerely,
> Theodore
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> > wrote:
> > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > >
> > > The RFC shows an example of a potential "simpler" attribute using a
> > > string instead of a class name. I honestly have no idea what this is
> > > supposed to do or what benefit it would have over normal attributes.
> > >
> > > The concept of attributes being a class name with optional arguments
> > > has been proven over many years by its use in docblock annotations,
> > > and if there was some deficiency in what this syntax allows it seems
> > > like we would have discovered it by now.
> >
> > I agree on just the string, but a closure would make 100% sense for
> > a decorating feature. Javascript and Python "Attributes" work as
> > decorators, i.e. they get called around the decorated function.
> >
> > It is not a completely unrealistic feature to think off:
> >
> > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> > function foo($message) {}
>
> As I understand it JavaScript decorators do not use anonymous
> functions for decorators like this, though. Instead you would make a
> named function and apply it with `@myFunc()` before the decorated
> function or class.
>
> Presumably we could accomplish the same thing in PHP with e.g. an
> `__invoke` method in the attribute class, without complicating the
> attribute syntax itself.
One other thought on this. I agree that decorators are not a
completely unrealistic future feature. However, it must be noted that
both JavaScript and Python use the `@Attr` syntax for decorators, and
the lack of an end delimiter in no way precludes this usage.
The whole point of a decorator is to offer syntax sugar for a common
reusable pattern (pass a function/class to another function which can
add additional information or behavior to it). It's not clear how an
anonymous closure would be useful for this, since it would not allow
reusability, which defeats the purpose.
So the argument that an end delimiter has "potential future benefits"
still lacks any realistic examples, and is countered by years of
proven usage of the `@Attr` syntax in docblocks and other languages.
Sincerely,
Theodore
--
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 Mon, Aug 17, 2020, 4:07 PM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei
> wrote:
>
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> wrote:
> > > However, ending delimiters in PHP have little to do with how "complex"
> > > a syntax construct is (which is a rather loose definition, anyway).
> > > As I've pointed out before, standalone statements and declarations
> > > generally require an end symbol, but modifiers before a declaration
> > > do not. Attributes fall into the latter category, and therefore the
> > > lack of an end delimiter is consistent.
> >
> > A docblock is also a "modifier" under your declaration and it has an
> > ending symbol.
>
> The difference is that a docblock comment is also a standalone
> declaration - it's quite common to add one at the top of a file
> that doesn't modify any other declaration.
>
Doesn't matter that you can add them anywhere.
Internally, doc comments (on structural elements) are stored and handled by
Reflection the same way that attributes are.
> > The RFC gives a definition of the complexity as just a token vs a
> > set of name, arugment_list and constant expression parser rules. It
> > shows an example porting an ORM\JoinTable Attribute, which has
> > arguments, named parameter usage, complex definitions of default
> > values (Strings, arrays).
> >
> > This piece of code probably touches 10-20 parser rules.
> >
> > Most modifiers don't even have a parser rule, as they only match
> > their token.
>
> In this comparison really the only "complex" part of an attribute is
> the argument list, which already has its own start and end delimiters.
> So I don't really see the need to add another end delimiter after the
> argument list end delimiter
>
Again, in the future we might introduce a new feature that might make
attributes have more complex parts than just an argument list. In this
case, `@@` or `@:` is only going to f*** us up.
> > Types are missing indeed, and they are more complex than a simple
> > token, but less complex than attribute declarations.
> >
> > I guess the difference is that union types are new, and type
> > definitions used to be simple. Attributes however are *new* and
> > already complex, so we still have the option of always enclosing
> > them.
>
> An attribute without arguments has essentially the same complexity
> that a type declaration has always had. The only part that is more
> complex is the optional argument list, which as stated before has
> its own start/end delimiters.
>
> > > The RFC suggests a benefit of "Consistent colouring for being an
> > > end of the attribute syntax and the keywords in between can use
> > > different colors." I don't really understand this argument. How
> > > would an end delimiter change the syntax highlighting provided by
> > > IDEs?
> >
> > If you consider the three elements of an attribute declaration:
> > 1. Syntax for Attributes 2. Atttribute Name 3. Arguments then if
> > you color them in three different ways, then with an ending symbol
> > it improves the human readability to have the end be in the same
> > color [as] the beginning.
>
> I see what you mean now. Personally I don't think a differently
> colored end bracket will be particularly helpful to readability,
> though. IDEs will already highlight the argument list start/end
> delimiters, and the different coloring of an attribute name from
> whatever token follows it will ensure readability whether there is
> an argument list or not. Ultimately perspectives on readability will
> differ, though, since it's a somewhat subjective consideration.
>
> > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > >
> > > The RFC shows an example of a potential "simpler" attribute using a
> > > string instead of a class name. I honestly have no idea what this is
> > > supposed to do or what benefit it would have over normal attributes.
> > >
> > > The concept of attributes being a class name with optional arguments
> > > has been proven over many years by its use in docblock annotations,
> > > and if there was some deficiency in what this syntax allows it seems
> > > like we would have discovered it by now.
> >
> > I agree on just the string, but a closure would make 100% sense for
> > a decorating feature. Javascript and Python "Attributes" work as
> > decorators, i.e. they get called around the decorated function.
> >
> > It is not a completely unrealistic feature to think off:
> >
> > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> > function foo($message) {}
>
> As I understand it JavaScript decorators do not use anonymous
> functions for decorators like this, though. Instead you would make a
> named function and apply it with `@myFunc()` before the decorated
> function or class.
>
> Presumably we could accomplish the same thing in PHP with e.g. an
> `__invoke` method in the attribute class, without complicating the
> attribute syntax itself.
> Best regards,
> Theodore
> --
>
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei wrote:
> On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown wrote:
> > However, ending delimiters in PHP have little to do with how "complex"
> > a syntax construct is (which is a rather loose definition, anyway).
> > As I've pointed out before, standalone statements and declarations
> > generally require an end symbol, but modifiers before a declaration
> > do not. Attributes fall into the latter category, and therefore the
> > lack of an end delimiter is consistent.
>
> A docblock is also a "modifier" under your declaration and it has an
> ending symbol.
The difference is that a docblock comment is also a standalone
declaration - it's quite common to add one at the top of a file
that doesn't modify any other declaration.
> The RFC gives a definition of the complexity as just a token vs a
> set of name, arugment_list and constant expression parser rules. It
> shows an example porting an ORM\JoinTable Attribute, which has
> arguments, named parameter usage, complex definitions of default
> values (Strings, arrays).
>
> This piece of code probably touches 10-20 parser rules.
>
> Most modifiers don't even have a parser rule, as they only match
> their token.
In this comparison really the only "complex" part of an attribute is
the argument list, which already has its own start and end delimiters.
So I don't really see the need to add another end delimiter after the
argument list end delimiter.
> Types are missing indeed, and they are more complex than a simple
> token, but less complex than attribute declarations.
>
> I guess the difference is that union types are new, and type
> definitions used to be simple. Attributes however are *new* and
> already complex, so we still have the option of always enclosing
> them.
An attribute without arguments has essentially the same complexity
that a type declaration has always had. The only part that is more
complex is the optional argument list, which as stated before has
its own start/end delimiters.
> > The RFC suggests a benefit of "Consistent colouring for being an
> > end of the attribute syntax and the keywords in between can use
> > different colors." I don't really understand this argument. How
> > would an end delimiter change the syntax highlighting provided by
> > IDEs?
>
> If you consider the three elements of an attribute declaration:
> 1. Syntax for Attributes 2. Atttribute Name 3. Arguments then if
> you color them in three different ways, then with an ending symbol
> it improves the human readability to have the end be in the same
> color [as] the beginning.
I see what you mean now. Personally I don't think a differently
colored end bracket will be particularly helpful to readability,
though. IDEs will already highlight the argument list start/end
delimiters, and the different coloring of an attribute name from
whatever token follows it will ensure readability whether there is
an argument list or not. Ultimately perspectives on readability will
differ, though, since it's a somewhat subjective consideration.
> > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> >
> > The RFC shows an example of a potential "simpler" attribute using a
> > string instead of a class name. I honestly have no idea what this is
> > supposed to do or what benefit it would have over normal attributes.
> >
> > The concept of attributes being a class name with optional arguments
> > has been proven over many years by its use in docblock annotations,
> > and if there was some deficiency in what this syntax allows it seems
> > like we would have discovered it by now.
>
> I agree on just the string, but a closure would make 100% sense for
> a decorating feature. Javascript and Python "Attributes" work as
> decorators, i.e. they get called around the decorated function.
>
> It is not a completely unrealistic feature to think off:
>
> @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> function foo($message) {}
As I understand it JavaScript decorators do not use anonymous
functions for decorators like this, though. Instead you would make a
named function and apply it with `@myFunc()` before the decorated
function or class.
Presumably we could accomplish the same thing in PHP with e.g. an
`__invoke` method in the attribute class, without complicating the
attribute syntax itself.
Best regards,
Theodore
--
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
possibility to keep @@ and add @{} as a second syntax for attributes
+1, but I would keep same prefix, ie. @@{} (or @@[]), for both syntaxes,
it is much easier for human eyes to search for one thing, also easier
for grep
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 17 Aug 2020 12:48, Andreas Leathley wrote:
As a possible addition/discussion point, I only noticed today that @{}
is a syntax that has not been mentioned yet, also not in any previous
discussions about attributes as far as I can tell. @{} currently leads
to a syntax error, so there is no BC break, and {} is common syntax for
grouping expressions in PHP, much more so than [], which is an
array-specific syntax.
Would it be a possibility to keep @@ and add @{} as a second syntax for
attributes, that can be used for grouping (for situations where that
makes sense) or other possibly future extensions? Then @@ would be a
good syntax for simple attribute definitions, and @{} could be an
alternative for people who want to group them or if any more complex
attribute features are added to the language later.
Because both sides of the "ending delimiter or no ending delimiter"
discussion do have some points in their favor, and it seems quite
individual what each person prefers. For a language it could be
beneficial to give some choices to the developer instead of foreseeing
each individual use case, and maybe attributes is such a feature.
I previously thought about suggesting both types of syntax (with and
without delimiters), but felt the current options all have too many side
effects to choose "two side effects" or two BC breaks. But the @@ BC
break seems the most harmless BC break of the bunch, and @{} does not
have a BC break, so these two option might be good together.
--
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 Sun, Aug 16, 2020 at 4:47 PM tyson andre
wrote:
> Hi Benjamin,
>
> > We are looking for further feedback from the community.
>
> Thanks, the updated RFC looks much better.
> Some more feedback on why the edge cases are a concern to me,
> and why the lack of an ending delimiter is similar to parsing problems
> already faced.
>
> I'd agree that restarting a two-week discussion period seems excessive,
> and a shorter one is fine with me.
>
Thank you for the feedback, the section on #[] forward compatibility is
something I want to improve a bit more today, your feedback helps a lot.
>
>
>
> The references section should probably also link to the other 2 RFC
> discussion threads
> https://externals.io/message/111416 and the RFC discussion thread
> https://externals.io/message/111218
>
>
>
> Developers who are new to PHP (e.g. learning by example) or those who
> spend most of their time programming in other languages such as Rust or
> Java or Golang
> might forget/not know that `#` is a supported line comment syntax, or that
> attributes were introduced in 8.0 (not an earlier release).
> They might see that code using these edge cases passes syntax checks in
> PHP 7.4 and 8.0, and assume it'd work the same way in both versions,
> leading to published code incorrectly marked as compatible with PHP 7.4.
>
> - PHP doesn't warn about calling a user-defined function too many
> parameters, making this harder to detect.
>
>
>
> The `#[]` syntax makes it possible and convenient to use attributes syntax,
> but causes various problems for end users of code using attributes syntax.
> I'd expect the drawbacks of bugs caused by edge cases such
> as those in
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#discussion_of_forwards_compatibility_procons
> to outweigh the benefits of being able to release attributes immediately.
>
> Putting attributes on the same line as parameters or closures or anonymous
> classes seems natural to do to me,
> and I'd expect releases would do it eventually, whether it be immediately
> in 8.0, years from now, etc.
>
> Suppose that package `A/A` supports PHP `7.4|^8.0`.
> It depends on a package `B/B` 2.0 which supports PHP 7.4.
> `B/B` depends on `C/C` `^4.0|^5.0`, where C/C 4.x supports PHP 7
> and C/C 5.0 drops support for PHP 7.
> C/C 5.x uses attribute syntax on the same line as other code,
> including several edge cases with one-line attributes that parse
> differently in php 7.0.
>
> ```
> public function doDbMaintenance(
> #[MyUnused] bool $log = false, // unused in db backend
> bool $doPotentiallyDestructiveUpdate = false,
> mixed $extraFlags = null,
> ) {...}
>
> // B/B calls doDbMaintenance($log = true)
> ```
>
> Then suppose that a maintainer or third-party packager (e.g. for a Linux
> distro) of `A/A`
> runs composer install with PHP 8.0 before building a package such as a
> phar, rpm, or tarball
> (or `vendor/` checked into git) from `A/A` 1.0.
> They would pull in B/B 2.0 and C/C 5.0, creating a release of A/A that was
> buggy
> but did not emit any parse, compilation, or runtime warnings if end users
> ran that release with php 7.4.
>
> Then the maintainers of `A/A` and `C/C` 5.0 would get bug reports for PHP
> 7.4 for mysterious behaviors with no warnings,
> which would be hard to reproduce and debug, despite all involved packages
> correctly specifying their dependencies.
> End users would also be inconvenienced by bugs that had no obvious
> indication or subtler symptoms that may take a long time to get reported.
>
> This could be worked around by
>
> 1. Setting `{"config": {"platform": {"php": "7.4.9"}}}` in composer.json
> of A/A,
>or by documenting that `composer install` should always be run with PHP
> 7.4,
>but I wouldn't expect new composer users to be aware of the ability to
> do that
>until they run into issues, and that doesn't help if A/A is a
> dependency of another package.
>
> 2. C/C 5.0 could exit() when bootstrapping when it's run in php 7,
>but that seems excessive and not currently done by libraries in my
> experience.
>
>
>
> If a developer needs to backport code or patches for php 8.0+ to php 7.4
> or older
> (e.g. to support legacy applications or OSes that make updating php
> impractical),
> the lack of a syntax error would make this backporting error prone
> if the developer didn't remember this incompatibility
> or learn about tools created to catch issues.
> (or didn't know about *up-to-date, bug-free* tools to downgrade php syntax)
>
>
>
> For
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#machine_scanning_for_end_of_attribute_declaration
> I'd agree that the lack of an ending delimiter makes token-based
> extraction more complicated but still practical,
> but it is a complexity that projects such as phpcs **would already face in
> similar syntaxes.**
> The problems with whitespace and comments and doc comments between tokens
> can be fixed by
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Mon, Aug 17, 2020 at 10:59 AM Alexandru Pătrănescu wrote: > On Sun, Aug 16, 2020 at 12:36 PM Benjamin Eberlei > wrote: > > > > We have updated the RFC with all (hopefully) of the feedback from this > > discussion: > > > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > > > Most notable changes are: > > - A new section with several subsections on the benefits of a closing > > delimiter / enclosing syntax. > > - A section on grouping pro/cons > > - Inclusion of @: as per Theodores request > > > > We are looking for further feedback from the community. > > Thanks for the work. Looks good. > An idea. > > Would the syntax @ be able to obtain a "No" on the "Breaks BC of > valid PHP 7 code" section while still being more or less the same as > #[Attr] or @[Attr] considering other features? > BTW, I'm thinking that it's good to have a "No" there. > > Sorry if proposing another syntax is making this an even more complex > problem. > It is ok to propose another syntax, at this point in time we are working around the @ and [] symbols, because of their familiarity with other languages attribute syntax. There is probably 100 potential syntaxes that we could use, @<> is a bit hard on the eyes as is <<>>, so i wouldn't call it a game changer in contrast to what we have already, so I would rather not include it. > > Regards, > Alex > > > On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote: > > > > > Hi, > > > > > > 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. > > > > > > FWIW, this has an excemption from the RM Sara as per [2]: > > > > > > > * Shorter Attribute Syntax Change > > > >- Joe/Derick - Please make sure this RFC moves along and reaches > > > > conclusion by beta3, as discussed previously. > > > > > > > > > cheers, > > > Derick > > > > > > [1] https://externals.io/message/111218#111261 > > > [2] https://externals.io/message/111286#111286 > > > > > > -- > > > 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 Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
wrote:
> On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei
> wrote:
>
> > We have updated the RFC with all (hopefully) of the feedback from
> > this discussion:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Most notable changes are:
> > - A new section with several subsections on the benefits of a closing
> > delimiter / enclosing syntax.
> > - A section on grouping pro/cons
> > - Inclusion of @: as per Theodores request
> >
> > We are looking for further feedback from the community.
>
> Hi Benjamin and Derick,
>
> Thank you for taking the time to further flesh out the RFC and
> include the `@:` syntax option. Overall it is a lot better now.
> However, I still have some concerns with several claims in the RFC
> that are inaccurate or incomplete, particularly in the "Discussion
> on Ending Delimiter / Enclosing Delimiters" section. [1]
>
> The RFC intro says "we should strongly favor a syntax with closing
> delimiter to keep consistency with other parts of the language". It
> is then argued that "Many complex syntax constructs in PHP have an
> ending delimiter", and therefore attributes should have one as well.
>
> However, ending delimiters in PHP have little to do with how "complex"
> a syntax construct is (which is a rather loose definition, anyway).
> As I've pointed out before, standalone statements and declarations
> generally require an end symbol, but modifiers before a declaration
> do not. Attributes fall into the latter category, and therefore the
> lack of an end delimiter is consistent.
>
A docblock is also a "modifier" under your declaration and it has an ending
symbol.
The RFC gives a definition of the complexity as just a token vs a set of
name, arugment_list and constant expression parser rules. It shows
an example porting an ORM\JoinTable Attribute, which has arguments, named
parameter usage, complex definitions of default values (Strings, arrays).
This piece of code probably touches 10-20 parser rules.
Most modifiers don't even have a parser rule, as they only match their
token.
>
> The RFC responds to this counterargument with a series of four
> claims, none of which is fully accurate in describing declaration
> modifiers:
>
> 1. Even if we only consider keyword declaration modifiers, the claim
> that "these modifier keywords all have only exactly one token that
> can immediately follow them, T_WHITESPACE" is not correct. Just as
> with attributes, modifier keywords can also be followed by a comment
> token (#, //, or /**/):
>
> @@Attribute// some comment
> final// some comment
> class Foo {...}
>
> Strangely, the RFC only lists keywords like public and final as
> declaration modifiers, and neglects to mention that type declarations
> are also in this category (which I have pointed out in all my
> previous responses to this argument).
>
> Type declarations can be not only followed by whitespace and comment
> tokens, but also a `T_VARIABLE` token:
>
> function foo(Type$bar) {}
>
> 2. The RFC goes on to claim that "[declaration modifiers] are all
> non-complex and are only made up of a handful ascii letters". Again,
> this fails to consider type declarations, which can contain the same
> non-ascii characters that attribute names can.
>
Types are missing indeed, and they are more complex than a simple token,
but less complex than attribute declarations.
I guess the difference is that union types are new, and type definitions
used to be simple. Attributes however are *new*
and already complex, so we still have the option of always enclosing them.
> 3. Next, the RFC says "these keywords are always on a single line".
> But union type declarations can be spread across multiple lines,
> and still don't have an end delimiter:
>
> function foo(
> \My\FullyQualified\ClassName
> |string $param
> ) {...}
>
> 4. Finally, the RFC says that "visibility keywords are only boolean
> or bitflags in Reflection, but Attributes are a full fledged
> `ReflectionAttribute` representing their own distinct language concept."
> You can probably guess where I'm going with this... Type declarations
> are likewise a fully fledged `ReflectionType` representing their own
> distinct language concept.
>
> So the RFC's argument that attributes need to have a distinct ending
> symbol for consistency is not convincing. The lack of an ending
> delimiter is fully consistent with other declaration modifiers,
> whether simple or complex.
>
> ## Benefits for IDEs and editors?
>
> The RFC suggests a benefit of "Consistent colouring for being an end
> of the attribute syntax and the keywords in between can use different
> colors." I don't really understand this argument. How would an end
> delimiter change the syntax highlighting provided by IDEs?
>
If you consider the three elements of an attribute declaration: 1. Syntax
for Attributes 2. Atttribute Name 3. Arguments
then if
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
As a possible addition/discussion point, I only noticed today that @{}
is a syntax that has not been mentioned yet, also not in any previous
discussions about attributes as far as I can tell. @{} currently leads
to a syntax error, so there is no BC break, and {} is common syntax for
grouping expressions in PHP, much more so than [], which is an
array-specific syntax.
Would it be a possibility to keep @@ and add @{} as a second syntax for
attributes, that can be used for grouping (for situations where that
makes sense) or other possibly future extensions? Then @@ would be a
good syntax for simple attribute definitions, and @{} could be an
alternative for people who want to group them or if any more complex
attribute features are added to the language later.
Because both sides of the "ending delimiter or no ending delimiter"
discussion do have some points in their favor, and it seems quite
individual what each person prefers. For a language it could be
beneficial to give some choices to the developer instead of foreseeing
each individual use case, and maybe attributes is such a feature.
I previously thought about suggesting both types of syntax (with and
without delimiters), but felt the current options all have too many side
effects to choose "two side effects" or two BC breaks. But the @@ BC
break seems the most harmless BC break of the bunch, and @{} does not
have a BC break, so these two option might be good together.
--
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 Sun, Aug 16, 2020 at 12:36 PM Benjamin Eberlei wrote: > > We have updated the RFC with all (hopefully) of the feedback from this > discussion: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > Most notable changes are: > - A new section with several subsections on the benefits of a closing > delimiter / enclosing syntax. > - A section on grouping pro/cons > - Inclusion of @: as per Theodores request > > We are looking for further feedback from the community. Thanks for the work. Looks good. An idea. Would the syntax @ be able to obtain a "No" on the "Breaks BC of valid PHP 7 code" section while still being more or less the same as #[Attr] or @[Attr] considering other features? BTW, I'm thinking that it's good to have a "No" there. Sorry if proposing another syntax is making this an even more complex problem. Regards, Alex > On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote: > > > Hi, > > > > 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. > > > > FWIW, this has an excemption from the RM Sara as per [2]: > > > > > * Shorter Attribute Syntax Change > > >- Joe/Derick - Please make sure this RFC moves along and reaches > > > conclusion by beta3, as discussed previously. > > > > > > cheers, > > Derick > > > > [1] https://externals.io/message/111218#111261 > > [2] https://externals.io/message/111286#111286 > > > > -- > > 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 > > > > -- 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 Mon, 17 Aug 2020 at 02:06, Theodore Brown wrote:
> ## Forcing @@ attributes to end with parenthesis?
>
> I don't really see the point of this section in the RFC.
The blame for that is on me, not Benjamin and Derek, as I repeatedly asked
why a compulsory ) could not be considered a closing delimiter.
> ## Attribute nesting
>
> The RFC points out that all the syntaxes can allow attribute nesting,
> which is true. However, it would be nice to include an example of
> potential future nesting for each syntax, as was included in the
> original Shorter Attribute Syntax RFC. The reason is that some of the
> syntaxes are less readable than others when nested (particularly `<<>>`,
> though arguably `#[]` and `@[]` as well since the attribute end
> delimiter can be confused with the end bracket of an array argument.
>
> @@JoinTable(
> "User_Group",
> @@JoinColumn("User_id", "id"),
> @@JoinColumn("Group_id", "id"),
> )
> private $groups;
>
> #[JoinTable(
> "User_Group",
> #[JoinColumn("User_id", "id")],
> #[JoinColumn("Group_id", "id")],
> )]
> private $groups;
>
> @[JoinTable(
> "User_Group",
> @[JoinColumn("User_id", "id")],
> @[JoinColumn("Group_id", "id")],
> )]
> private $groups;
>
> < "User_Group",
> <>,
> <>,
> )>>
> private $groups;
>
> @:JoinTable(
> "User_Group",
> @:JoinColumn("User_id", "id"),
> @:JoinColumn("Group_id", "id"),
> )
> private $groups;
>
Good catch.
Peter
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei wrote:
> We have updated the RFC with all (hopefully) of the feedback from
> this discussion:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Most notable changes are:
> - A new section with several subsections on the benefits of a closing
> delimiter / enclosing syntax.
> - A section on grouping pro/cons
> - Inclusion of @: as per Theodores request
>
> We are looking for further feedback from the community.
Hi Benjamin and Derick,
Thank you for taking the time to further flesh out the RFC and
include the `@:` syntax option. Overall it is a lot better now.
However, I still have some concerns with several claims in the RFC
that are inaccurate or incomplete, particularly in the "Discussion
on Ending Delimiter / Enclosing Delimiters" section. [1]
The RFC intro says "we should strongly favor a syntax with closing
delimiter to keep consistency with other parts of the language". It
is then argued that "Many complex syntax constructs in PHP have an
ending delimiter", and therefore attributes should have one as well.
However, ending delimiters in PHP have little to do with how "complex"
a syntax construct is (which is a rather loose definition, anyway).
As I've pointed out before, standalone statements and declarations
generally require an end symbol, but modifiers before a declaration
do not. Attributes fall into the latter category, and therefore the
lack of an end delimiter is consistent.
The RFC responds to this counterargument with a series of four
claims, none of which is fully accurate in describing declaration
modifiers:
1. Even if we only consider keyword declaration modifiers, the claim
that "these modifier keywords all have only exactly one token that
can immediately follow them, T_WHITESPACE" is not correct. Just as
with attributes, modifier keywords can also be followed by a comment
token (#, //, or /**/):
@@Attribute// some comment
final// some comment
class Foo {...}
Strangely, the RFC only lists keywords like public and final as
declaration modifiers, and neglects to mention that type declarations
are also in this category (which I have pointed out in all my
previous responses to this argument).
Type declarations can be not only followed by whitespace and comment
tokens, but also a `T_VARIABLE` token:
function foo(Type$bar) {}
2. The RFC goes on to claim that "[declaration modifiers] are all
non-complex and are only made up of a handful ascii letters". Again,
this fails to consider type declarations, which can contain the same
non-ascii characters that attribute names can.
3. Next, the RFC says "these keywords are always on a single line".
But union type declarations can be spread across multiple lines,
and still don't have an end delimiter:
function foo(
\My\FullyQualified\ClassName
|string $param
) {...}
4. Finally, the RFC says that "visibility keywords are only boolean
or bitflags in Reflection, but Attributes are a full fledged
`ReflectionAttribute` representing their own distinct language concept."
You can probably guess where I'm going with this... Type declarations
are likewise a fully fledged `ReflectionType` representing their own
distinct language concept.
So the RFC's argument that attributes need to have a distinct ending
symbol for consistency is not convincing. The lack of an ending
delimiter is fully consistent with other declaration modifiers,
whether simple or complex.
## Benefits for IDEs and editors?
The RFC suggests a benefit of "Consistent colouring for being an end
of the attribute syntax and the keywords in between can use different
colors." I don't really understand this argument. How would an end
delimiter change the syntax highlighting provided by IDEs?
Another suggested benefit is that IDEs can "Implement regions to
open/close the grouped declaration of one or multiple attributes."
But IDEs can still do this without an end delimiter, and groups of
attributes could even be opened/closed independently by separating
them with an empty line (which should improve readability for humans
as well).
## Easier machine parsing?
The RFC shows a list of different ways that attributes with the `@@`
syntax can end, and claims "This makes programmatic token based
scanning for attribute syntax without a closing delimiter such as `@@`
unnecessarily complicated."
But I've worked with userland token stream scanners myself, and it's
not difficult to skip `T_WHITESPACE` and `T_COMMENT` tokens. Once you do
that, parsing an attribute is as simple as finding any `T_ATTRIBUTE`
token followed by the name token, then checking for an optional
argument list. If there's not an argument list, that's then end of
the attribute, otherwise the end is the end of the argument list.
With the `@[]` and `#[]` syntaxes, a userland token parser is actually
*more* complex due to grouping. It not only has to do the same things
listed above, but it also has
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Hi Benjamin,
> We are looking for further feedback from the community.
Thanks, the updated RFC looks much better.
Some more feedback on why the edge cases are a concern to me,
and why the lack of an ending delimiter is similar to parsing problems already
faced.
I'd agree that restarting a two-week discussion period seems excessive, and a
shorter one is fine with me.
The references section should probably also link to the other 2 RFC discussion
threads
https://externals.io/message/111416 and the RFC discussion thread
https://externals.io/message/111218
Developers who are new to PHP (e.g. learning by example) or those who spend
most of their time programming in other languages such as Rust or Java or Golang
might forget/not know that `#` is a supported line comment syntax, or that
attributes were introduced in 8.0 (not an earlier release).
They might see that code using these edge cases passes syntax checks in PHP 7.4
and 8.0, and assume it'd work the same way in both versions, leading to
published code incorrectly marked as compatible with PHP 7.4.
- PHP doesn't warn about calling a user-defined function too many parameters,
making this harder to detect.
The `#[]` syntax makes it possible and convenient to use attributes syntax,
but causes various problems for end users of code using attributes syntax.
I'd expect the drawbacks of bugs caused by edge cases such
as those in
https://wiki.php.net/rfc/shorter_attribute_syntax_change#discussion_of_forwards_compatibility_procons
to outweigh the benefits of being able to release attributes immediately.
Putting attributes on the same line as parameters or closures or anonymous
classes seems natural to do to me,
and I'd expect releases would do it eventually, whether it be immediately in
8.0, years from now, etc.
Suppose that package `A/A` supports PHP `7.4|^8.0`.
It depends on a package `B/B` 2.0 which supports PHP 7.4.
`B/B` depends on `C/C` `^4.0|^5.0`, where C/C 4.x supports PHP 7
and C/C 5.0 drops support for PHP 7.
C/C 5.x uses attribute syntax on the same line as other code,
including several edge cases with one-line attributes that parse differently in
php 7.0.
```
public function doDbMaintenance(
#[MyUnused] bool $log = false, // unused in db backend
bool $doPotentiallyDestructiveUpdate = false,
mixed $extraFlags = null,
) {...}
// B/B calls doDbMaintenance($log = true)
```
Then suppose that a maintainer or third-party packager (e.g. for a Linux
distro) of `A/A`
runs composer install with PHP 8.0 before building a package such as a phar,
rpm, or tarball
(or `vendor/` checked into git) from `A/A` 1.0.
They would pull in B/B 2.0 and C/C 5.0, creating a release of A/A that was
buggy
but did not emit any parse, compilation, or runtime warnings if end users ran
that release with php 7.4.
Then the maintainers of `A/A` and `C/C` 5.0 would get bug reports for PHP 7.4
for mysterious behaviors with no warnings,
which would be hard to reproduce and debug, despite all involved packages
correctly specifying their dependencies.
End users would also be inconvenienced by bugs that had no obvious indication
or subtler symptoms that may take a long time to get reported.
This could be worked around by
1. Setting `{"config": {"platform": {"php": "7.4.9"}}}` in composer.json of A/A,
or by documenting that `composer install` should always be run with PHP 7.4,
but I wouldn't expect new composer users to be aware of the ability to do
that
until they run into issues, and that doesn't help if A/A is a dependency of
another package.
2. C/C 5.0 could exit() when bootstrapping when it's run in php 7,
but that seems excessive and not currently done by libraries in my
experience.
If a developer needs to backport code or patches for php 8.0+ to php 7.4 or
older
(e.g. to support legacy applications or OSes that make updating php
impractical),
the lack of a syntax error would make this backporting error prone
if the developer didn't remember this incompatibility
or learn about tools created to catch issues.
(or didn't know about *up-to-date, bug-free* tools to downgrade php syntax)
For
https://wiki.php.net/rfc/shorter_attribute_syntax_change#machine_scanning_for_end_of_attribute_declaration
I'd agree that the lack of an ending delimiter makes token-based extraction
more complicated but still practical,
but it is a complexity that projects such as phpcs **would already face in
similar syntaxes.**
The problems with whitespace and comments and doc comments between tokens can
be fixed by filtering out whitespace and comments before/while looking to the
end of a token.
Projects such as nikic/php-parser or microsoft/tolerant-php-parser would be
what I'd recommend for new code/scripts,
but this is impractical for large existing codebases with third party plugins
such as phpcs.
A stack-based approach is used for `@[` or `#[`.
A stack-based approach would also be used
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
I have one major issues with the examples.
Syntax Side by Side: The properties are annotated (with attributes)
inline which is the opposited of common usage now (with annotation).
Discussion on Grouping Pro/Cons: But since this depends on the coding
style the user... No, this should be consulted with PSR people and their
recommendations should be discussed there.
Enclosing Delimiters - Complexity of Attribute Declaration: there should
be example on left side without and on right side with - I do not see
how delimiters will actually help
Discussion on grep'ability - the arguments against are theoretical,
imports are not very often aliased, this is clearly a con for grouping
Excl. the <<>> syntax (which I think is not good because of generics
that will come sooner or later), all other examples are about good
prefix for attributes. So I think we should discuss the best prefix and
separately if we want to allow grouping with "[" or even with "{".
The most prefer syntax can be @: for ungrouped attributes and @:[] for
grouped one, but this combination is not discussed there.
With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
Michael Voříšek
On 16 Aug 2020 11:36, Benjamin Eberlei wrote:
We have updated the RFC with all (hopefully) of the feedback from this
discussion:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
Most notable changes are:
- A new section with several subsections on the benefits of a closing
delimiter / enclosing syntax.
- A section on grouping pro/cons
- Inclusion of @: as per Theodores request
We are looking for further feedback from the community.
On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
Hi,
Out of Banjamin's suggestion[1 [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.
FWIW, this has an excemption from the RM Sara as per [2 [2]]:
* Shorter Attribute Syntax Change
- Joe/Derick - Please make sure this RFC moves along and reaches
conclusion by beta3, as discussed previously.
cheers,
Derick
[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286
--
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
Links:
--
[1] https://externals.io/message/111218#111261
[2] https://externals.io/message/111286#111286
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
We have updated the RFC with all (hopefully) of the feedback from this discussion: https://wiki.php.net/rfc/shorter_attribute_syntax_change Most notable changes are: - A new section with several subsections on the benefits of a closing delimiter / enclosing syntax. - A section on grouping pro/cons - Inclusion of @: as per Theodores request We are looking for further feedback from the community. On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote: > Hi, > > 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. > > FWIW, this has an excemption from the RM Sara as per [2]: > > > * Shorter Attribute Syntax Change > >- Joe/Derick - Please make sure this RFC moves along and reaches > > conclusion by beta3, as discussed previously. > > > cheers, > Derick > > [1] https://externals.io/message/111218#111261 > [2] https://externals.io/message/111286#111286 > > -- > 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 Mon, 10 Aug 2020, Christoph M. Becker wrote: > On 10.08.2020 at 10:35, Derick Rethans wrote: > > > On Fri, 7 Aug 2020, Theodore Brown wrote: > > > >> - Used by other language: > >> - This is listed as an advantage for `#[]` and `<<>>`. However, the > >> table > >> fails to point out that Hack is migrating away from `<<>>` to `@Attr`. > > > > It can only do that because they are removing @ as the shut up operator, > > which ain't going to happen in PHP. > > If we could afford the luxury of removing the @ operator, would you > prefer @ for attributes? No. 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 10.08.2020 at 10:35, Derick Rethans wrote: > On Fri, 7 Aug 2020, Theodore Brown wrote: > >> - Used by other language: >> - This is listed as an advantage for `#[]` and `<<>>`. However, the table >> fails to point out that Hack is migrating away from `<<>>` to `@Attr`. > > It can only do that because they are removing @ as the shut up operator, > which ain't going to happen in PHP. If we could afford the luxury of removing the @ operator, would you prefer @ for attributes? -- Christoph M. Becker -- 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 Fri, 7 Aug 2020, Theodore Brown wrote: > On Fri, Aug 7, 2020 at 6:03 AM Derick Rethans wrote: > > > On Fri, 7 Aug 2020, Theodore Brown wrote: > > > > > Even if we assume the implementation is only about 30 lines, it's > > > still extra complexity that I don't understand the benefit of. I > > > sincerely would like to know what advantage there is of grouped > > > attributes over the `@@` syntax. > > > > It was very *specifically* voted for: > > https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes > > It was specifically voted for the `<<>>` syntax, with the explicit > qualification that "This feature would be superseded by any other RFC > getting accepted that changes the syntax." This is exactly what > happened when the Shorter Attribute Syntax RFC was accepted. But there wasn't a *specific* vote to remove that, like there was one to enable it. > > You still haven't addressed any of the deficiencies that the other > > alternatives don't have: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal > > I'm not sure which deficiencies you mean, but let's briefly go > through the table in the RFC to make sure nothing has been missed: > > - Number of required Characters: > - `@@` has the advantage here. But @@ takes up 94 pixels, whereas #[] only takes up 77 (and @[] 83), so clearly better. > - Has End Delimiter: > - This isn't clearly a pro or a con in itself. But you haven't said why it is better that *not having it* is better. > - Allows Grouping: > - As discussed before, `@@` has the advantage of being equally > concise without this added complexity. I have no idea what that means. > - Forward Compatibility in PHP 7: > - This is at best a temporary benefit of `#[]` which will be > irrelevant in a few years, at worst a source of confusion and bugs > when code intended for PHP 8 runs on PHP 7 with different results. But it helps now, maybe only a little, but it does. > - Breaks BC of valid PHP 7 code: > - All syntaxes but `<<>>` technically have a BC break. There really > should be a separate line in the table for "Breaks useful syntax", > since `#[]` and `@[]` have this deficiency, but `@@` does not. @[] and #[] don't break "useful syntax" either. > > - Used by other language: > - This is listed as an advantage for `#[]` and `<<>>`. However, the table > fails to point out that Hack is migrating away from `<<>>` to `@Attr`. It can only do that because they are removing @ as the shut up operator, which ain't going to happen in PHP. > Furthermore, while `#[]` has the same start/end symbols as Rust, the rest > of the grammar/semantics vary significantly. E.g. these are valid Rust > attributes (see https://doc.rust-lang.org/reference/attributes.html): I've never said that it has the same semantics, only that the syntax is familiar. It still stands that nothing uses @@. > - Familiar with Docblock Usage: > - `@@` has the advantage here once more. @@ isn't used in docblocks. > - Tokens used: > - This isn't clearly a pro or con in itself. [citation required] > - Changes the lexing of **remaining** tokens: > - This is apparently a con for `#[]`. That's why there is @[] now, which is a compromise, something that you don't seem to be interested in caring about. 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
Hi everyone. I’m not a PHP internal, just a modest PHP developer. But I felt
a desire to share my observation on “@@”.
Some symbols looks very okay when doubled. For example, we use “//” for comments
and “||” for logical alternative. They are okay, because they contains only
two parallel lines. There is a symbol like that in mathematics: “∥”. Programmer
fonts (for example Fira Code) convert doubled characters to an appropriate
ligature.
On the other side, the at sign “@” contains the small letter “a” in a circle.
It’s feels full to the brim. It’s complete and closed whole. It’s like a donut
with tasty filling. ;-) But when we double it, the resulting “@@” is bloated.
Even intuitively not right.
Why “@@” was proposed? Because “@” is already taken. Sorry, but it’s born out of
helplessness (in the most visible way in comparison to other syntaxes). And
maybe this is the reason why some of community members feel bad about it
(no matter of technical arguments).
One could argue that it’s a matter of taste. Well, only to some degree. Mankind
invented typography and editing, so rules of esthetic and harmonious writing
exist. PHP has PSR-12 (“Extended Coding Style”) for this.
Now I’d like to draw your attention to this syntax:
<<
@Assert\NotNull
@Assert\Type('string')
@ORM\Column(type='string')
>>
private string $username;
It has some good points. First of all, it uses single “@”. This is a popular
choice in other programming languages, including JavaScript – a natural
companion of PHP in Web programming.
\
Nesting attributes in this syntax is very natural.
The mental model of the syntax reads like that: Here I put “<<” and it starts
a metadata (metaprogramming) context. Now I put “@” for every attribute. Let’s
finish it with “>>”. I like this separation of metaprograming and a real code.
It’s something that remainds me DocBlock.
The syntax has it’s weak points, of course. For example, a single attribute
looks a bit verbose. A good syntax highliting may help to blunt this impression.
<<@Deprecated>>
public function doSomething()
Moreover, the more spaced syntax may be preffered (and I like it more):
<<
@Deprecated
>>
public function doSomething()
Another option would be to use a keyword, just like “new” with a class name.
meta Assert\NotNull
meta Assert\Type('string')
meta ORM\Column(type='string')
private string $username;
Going back to nested attributes, what I don’t like about “@[]” and “#[]” is that
the at sing is at first before brackets, but for nested attributes it will be
put together with an attribute name:
@[Attribute(@NestedAttribute('text')]
I believe this RFC should have an example section to show every syntax in
practice.
Best wishes to all of you.
--
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
Hello Derick & Internals,
I am a daily user of PHP and read through all the recent discussions about the
attribute syntax, and thought I could add some slightly different viewpoints
from an "end-user" who uses the current annotations a lot. This is my first time
posting, so I am hoping I am doing this the right way ;-)
Currently, I am favoring @@, although I don't have strong preferences to other
syntax if it is more useful in some way. Why I prefer @@:
1. The @ symbol is hardly used in PHP, except for error suppression and within
comments, so searching and scanning over code with @@ works well and does not
have much ambiguity. The syntax with [] (and a symbol) is very close to the PHP
syntax for arrays and destructuring, and would now have a different meaning in
addition to that. This is not the case for C/C++/C# as far as I can tell, as []
is rarely used in those languages so having [] for attributes there makes it
quite recognizable/unique.
2. A big argument about the ending delimiter is about consistency. Yet isn't an
attribute almost like the "new" keyword, which also only allows a class name and
then optionally some arguments passed to the constructor? It is not like you can
define anything but a class + arguments as an attribute, and "new" does not have
starting and ending delimiters.
3. What would starting and ending delimiters be used for except for grouping
attributes? I would be really interested in use cases, and if delimiters are
important, then a few real-world examples why they are important and how the
syntax will come in handy later would be the best argument for them. After using
the current annotations for years it has not occured to me that something is
fundamentally missing, and attributes have been used for many years as
annotations in PHP as well as in other languages, so there should be some
evidence/examples.
4. If at a later time grouping or more options become necessary, something like
@@{} could be an optional syntax. Using {} to optionally group something in PHP
has a lot of precendence, and if it is only optional, it seems like a reasonable
addition while still having the simple just-one-class-with-arguments attributes.
When looking at the new RFC, I feel like none of the syntax arguments in the RFC
are very self-explanatory or even would be a factor why I would prefer them or
not. A larger explanation about each syntax, some real code samples with each
syntax (possibly with colors) and longer pro/con arguments would be a lot better
for an informed decision, so if there is a lot of contention around the syntax,
I think more time to flesh out such an RFC and then do it for 8.1 would be
better. At the same time I do feel like @@ would be a good syntax, but if there
are open questions or more discussions to be had it might be better to have the
time for those compared to having hasty discussions now with a hasty vote where
everyone will be unhappy at the end.
Best regards,
Andreas
--
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
> > > This is some new complexity, even if only a small amount right now. > My question remains about how much more added complexity it will > require later if we implement extensions like nested attributes. > What? Are you actually saying that 30 lines of code add "complexity"? I think you should look more at the PHP source code before going to these nonsensical conclusions. PHP is a fully fledged language, not a "let's write the shortest code possible" competition. As for the nested attributes, you can implement those with simple recursion. You are trying to create problems here that don't exist. > Yes, PHP has historically been rather verbose in some ways. > Thankfully this has been gradually changing, with the short array > syntax added in 5.4, and more recently short arrow functions, > constructor property promotion, and the match expression having an > explicit goal to reduce verbosity. > No offense intended but saying that 1 extra character somehow adds verbosity is quite honestly, one of the stupidest things I have heard. While we at it, let's also rename other keywords: `function` to `f`, `while` to `w` and `static` to `s`. You know, to save those few extra characters. > What is the goal of the grouped attribute construct? I still haven't > received an answer about what makes it better than `@@`. > You can't compare attribute syntax against attribute feature. You better tell me why `@@` is better than `@[]` using arguments and not with "boo, I have to type 1 extra character with `@[]`". As for the grouped attributes. Why do we allow grouped properties and class constants? It's alternative code style that some might prefer. > > Aren't docblock annotations only wrapped in /** */ because they have to > be inside a comment? There is no need for this with the native > attribute syntax. To me, the `#[]` and `@[]` tokens don't at all look > similar to docblock comment boundaries, anyway. > Even more so with `@@`, which look nothing alike to docblocks. Just because docblock annotations contain the same character as attribute syntax, it doesn't magically mean "it's like docblocks". Because if so, `@[]` looks far far more like docblocks than `@@`. > Best regards, > Theodore Best regards, Benas
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Fri, Aug 7, 2020 at 6:03 AM Derick Rethans wrote:
> On Fri, 7 Aug 2020, Theodore Brown wrote:
>
> > Even if we assume the implementation is only about 30 lines, it's
> > still extra complexity that I don't understand the benefit of. I
> > sincerely would like to know what advantage there is of grouped
> > attributes over the `@@` syntax.
>
> It was very *specifically* voted for:
> https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes
Hi Derick,
It was specifically voted for the `<<>>` syntax, with the explicit
qualification that "This feature would be superseded by any other RFC
getting accepted that changes the syntax." This is exactly what
happened when the Shorter Attribute Syntax RFC was accepted.
> You still haven't addressed any of the deficiencies that the other
> alternatives don't have:
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal
I'm not sure which deficiencies you mean, but let's briefly go
through the table in the RFC to make sure nothing has been missed:
- Number of required Characters:
- `@@` has the advantage here.
- Has End Delimiter:
- This isn't clearly a pro or a con in itself.
- Allows Grouping:
- As discussed before, `@@` has the advantage of being equally
concise without this added complexity.
- Forward Compatibility in PHP 7:
- This is at best a temporary benefit of `#[]` which will be
irrelevant in a few years, at worst a source of confusion and bugs
when code intended for PHP 8 runs on PHP 7 with different results.
- Breaks BC of valid PHP 7 code:
- All syntaxes but `<<>>` technically have a BC break. There really
should be a separate line in the table for "Breaks useful syntax",
since `#[]` and `@[]` have this deficiency, but `@@` does not.
- Used by other language:
- This is listed as an advantage for `#[]` and `<<>>`. However, the table
fails to point out that Hack is migrating away from `<<>>` to `@Attr`.
Furthermore, while `#[]` has the same start/end symbols as Rust, the rest
of the grammar/semantics vary significantly. E.g. these are valid Rust
attributes (see https://doc.rust-lang.org/reference/attributes.html):
#[rustfmt::skip]
struct S {}
#[clippy::cyclomatic_complexity = "100"]
pub fn f() {}
This is quite different from PHP's semantics, so it's not clear that
copying the same start/end symbol would really be a benefit for us.
Also note that unlike PHP, `#` does not start a comment in Rust.
- Familiar with Docblock Usage:
- `@@` has the advantage here once more.
- Tokens used:
- This isn't clearly a pro or con in itself.
- Changes the lexing of **remaining** tokens:
- This is apparently a con for `#[]`.
Ultimately I think `@@` does the best job balancing a very small BC
break with concise, familiar syntax that can cleanly support nested
attributes in the future. And since it avoids the need for attribute
grouping it also has the simplest implementation.
Kind regards,
Theodore
--
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 Fri, Aug 7, 2020 at 3:32 AM Benjamin Eberlei wrote: > On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown wrote: > > On Thu, Aug 6, 2020 at 12:30 PM Benas IML > > > wrote: > > > > > Hey Theodore, > > > > > > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown > > > > wrote: > > > > > > > While none of our syntax options are perfect, I believe @@ has the > > > > best long-term tradeoffs because: > > > > > > > > - It doesn't break useful syntax > > > > > > Fair enough. > > > > > > > - It is equally or more concise than grouped attributes without > > > > adding complexity to the parser/compiler > > > > > > Are we really going to debate that ~30 lines of code add complexity? > > > > Hi Benas, > > > > I don't know how many lines of code it will be, since an > > implementation for it has never been finished. The patch currently > > linked in the RFC does not implement it. > > Curious what brings you to claim an implementation has never been > finished when it was accepted by RFC vote? > > Grouping certainly has a finished implementation, Martin and I had it > working for the original RFC, then when we removed it for the original > vote had a working patch and PR as part of the Amendments RFC. Hi Benjamin, Apologies, I didn't realize the grouped attribute implementation was completely finished before. When it was dropped from the Attribute Amendments pull request, a bunch of other changes still had to be made before it was ready to merge, and I assumed that some changes would have also been required for attribute grouping. Thank you for the correction. > I now ported the patch to the @[] syntax PR here: [updated link] > https://github.com/php/php-src/pull/5928/commits/597688fd5b0a41d23028454b62ba25f950f35a16 > The zend_compile.c diff looks a bit complex, but it's really only 5 > new lines for a new for loop over the groups and all existing code > one level deeper. > > All in all the attribute grouping patch adds 26 new lines (and then > tests) all restricted within the existing attribute parser rules and > the functions compiling attribute code. This adds no complexity at all. This is some new complexity, even if only a small amount right now. My question remains about how much more added complexity it will require later if we implement extensions like nested attributes. > > Even if we assume the implementation is only about 30 lines, it's > > still extra complexity that I don't understand the benefit of. I > > sincerely would like to know what advantage there is of grouped > > attributes over the `@@` syntax. > > > > - It is equally or more verbose than `@@` in real-world use cases > > You keep bringing up verbosity like our primary language design goal > is to reduce it, PHP is the most verbose language I know. Everything > in PHP requires more characters than in other languages. Keywords are > usually long, variables need an extra $ in front. You have to use > $this-> as no implicit context exists. Functions need to be prefixed > by "array_", "str_" instead of methods on the objects. Yes, PHP has historically been rather verbose in some ways. Thankfully this has been gradually changing, with the short array syntax added in 5.4, and more recently short arrow functions, constructor property promotion, and the match expression having an explicit goal to reduce verbosity. > The primary design goal of a language construct in PHP is not to > reduce verbosity. What is the goal of the grouped attribute construct? I still haven't received an answer about what makes it better than `@@`. > > `@@` avoids the need for additional complexity, special cased syntax, > > and having to modify extra lines when adding/removing separate > > attributes. > > > > > > - It is conceptually closest to the docblock syntax the PHP > > > > community is familiar with > > > > > > Well, if `@@` is similar to `@` (to me it isn't), we can say that > > > `@[]` is also similar to `@`. > > > > I would agree that `@[]` is more similar than `#[]` is. But arguably > > `@@` is still the closest since docblock annotations don't require > > being wrapped in array brackets. > > But docblocks are wrapped in /** */, enclosing the whole declaration > of them. > > Both @[] and #[] are comparable with /** */ as metadata **boundary**. > The attribute itself has no symbol prefixes or alike, it's just the > class name. > > This is a very close translation to how docblocks with userland > doc-params work, in my opinion this makes all enclosed syntaxes much > more in line with existing syntax, regardless of symbols used. Aren't docblock annotations only wrapped in /** */ because they have to be inside a comment? There is no need for this with the native attribute syntax. To me, the `#[]` and `@[]` tokens don't at all look similar to docblock comment boundaries, anyway. Best regards, Theodore -- 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 Fri, 7 Aug 2020 at 12:03, Derick Rethans wrote: > > You still haven't addressed any of the deficiencies that the other > alternatives don't have: > https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal > That table would be a lot more useful to steer the discussion if it was accompanied by an explanation of each of the factors, as some of them are extremely vague: * Do the three "Yes"es in the "Difficulties with Userland Parsers" relate to the same problem? What is it specifically, and how does <> avoid it? Is it really true that <> has _no_ difficulties for userland parsers, or just that it avoids that particular problem? * "Number of required characters" is the number for a single, ungrouped attribute. The number of characters saved by grouped attributes would be a more useful measure than just whether they're possible. * There is no explanation of _why_ end delimiters are an important factor. * If it is important, my question before stands as to why "@@Attr()" with mandatory parentheses wouldn't receive a "Yes" in this row. * "Familiar with Docblock Usage" seems to be rather subjective; is it the "@" that makes it familiar? the lack of extra brackets? I'm not sure it's fair to boil this down to a straight yes/no. * "Tokens Used" seems to be an implementation detail, with no explanation of why this would make a difference to anyone's vote. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Fri, 7 Aug 2020, Theodore Brown wrote: > On Thu, Aug 6, 2020 at 12:30 PM Benas IML wrote: > > > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote: > > > > > While none of our syntax options are perfect, I believe @@ has the > > > best long-term tradeoffs because: > > > > > > - It doesn't break useful syntax > > > > Fair enough. > > > > > - It is equally or more concise than grouped attributes without > > > adding complexity to the parser/compiler > > > > Are we really going to debate that ~30 lines of code add complexity? > > I don't know how many lines of code it will be, since an > implementation for it has never been finished. The patch currently > linked in the RFC does not implement it. > > Even if we assume the implementation is only about 30 lines, it's > still extra complexity that I don't understand the benefit of. I > sincerely would like to know what advantage there is of grouped > attributes over the `@@` syntax. It was very *specifically* voted for: https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes1 The complexity is minimal: https://github.com/php/php-src/pull/5928/commits/597688fd5b0a41d23028454b62ba25f950f35a16 And most of the change is just indentation. You still haven't addressed any of the deficiencies that the other alternatives don't have: https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal > I would agree that `@[]` is more similar than `#[]` is. But arguably > `@@` is still the closest since docblock annotations don't require > being wrapped in array brackets. They're instead wrapped in /** … */ though, which also acts like a grouping structure. > > > - It is aligned with the attribute semantics of the majority of C > > > family languages > > > > In what way `#[]` or `@[]` aren't? > > The majority of C family languages use `@Attr` without an extra end > symbol. PHP isn't C though—hack, C has a function 'creat()', so that argument doesn't really mean much. 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 Fri, Aug 7, 2020 at 2:24 AM Theodore Brown
wrote:
> On Thu, Aug 6, 2020 at 12:30 PM Benas IML
> wrote:
>
> > Hey Theodore,
> >
> > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown
> wrote:
> >
> > > While none of our syntax options are perfect, I believe @@ has the
> > > best long-term tradeoffs because:
> > >
> > > - It doesn't break useful syntax
> >
> > Fair enough.
> >
> > > - It is equally or more concise than grouped attributes without
> > > adding complexity to the parser/compiler
> >
> > Are we really going to debate that ~30 lines of code add complexity?
>
> Hi Benas,
>
> I don't know how many lines of code it will be, since an
> implementation for it has never been finished. The patch currently
> linked in the RFC does not implement it.
>
Curious what brings you to claim an implementation has never been finished
when it was accepted by RFC vote?
Grouping certainly has a finished implementation, Martin and I had it
working for the original RFC, then when we removed it for the original vote
had a working patch and PR as part of the Amendments RFC.
I now ported the patch to the @[] syntax PR here:
https://github.com/php/php-src/pull/5928/commits/c69e2de26c42c583a8ca0fa579c1be69d40bfc454
The zend_compile.c diff looks a bit complex, but it's really only 5 new
lines for a new for loop over the groups and all existing code one level
deeper.
All in all the attribute grouping patch adds 26 new lines (and then tests)
all restricted within the existing attribute parser rules and the functions
compiling attribute code. This adds no complexity at all.
> Even if we assume the implementation is only about 30 lines, it's
> still extra complexity that I don't understand the benefit of. I
> sincerely would like to know what advantage there is of grouped
> attributes over the `@@` syntax.
>
> - It is equally or more verbose than `@@` in real-world use cases
>
You keep bringing up verbosity like our primary language design goal is to
reduce it, PHP is the most verbose language I know. Everything in PHP
requires more characters than in other languages. Keywords are usually
long, variables need an extra $ in front. You have
to use $this-> as no implicit context exists. Functions need to be prefixed
by "array_", "str_" instead of methods on the objects.
The primary design goal of a language construct in PHP is not to reduce
verbosity.
> - Adding or removing a second attribute with grouping can require
> modifying multiple lines, adding unnecessary noise to diffs:
>
> @@SomeAttribute("value")
> @@AnotherAttribute("value") # can be added/removed independently
> function foo() {}
>
> # vs.
>
> @[SomeAttribute("value")] # changes to:
>
> @[
> SomeAttribute("value"),
> AnotherAttribute("value"), # not added/removed independently
> ]
> function foo() {}
>
> - How much more added complexity will the grouped syntax require if
> we add nested attributes in the future? At the least it will have to
> be special-cased in some way, either to disallow grouping for nested
> attributes or to treat the grouped syntax the same as an array.
>
`@@` avoids the need for additional complexity, special cased syntax,
> and having to modify extra lines when adding/removing separate
> attributes.
>
> > > - It is conceptually closest to the docblock syntax the PHP
> > > community is familiar with
> >
> > Well, if `@@` is similar to `@` (to me it isn't), we can say that
> > `@[]` is also similar to `@`.
>
> I would agree that `@[]` is more similar than `#[]` is. But arguably
> `@@` is still the closest since docblock annotations don't require
> being wrapped in array brackets.
But docblocks are wrapped in /** */, enclosing the whole declaration of
them.
Both @[] and #[] are comparable with /** */ as metadata **boundary**. The
attribute
itself has no symbol prefixes or alike, it's just the class name.
This is a very close translation to how docblocks with userland doc-params
work,
in my opinion this makes all enclosed syntaxes much more in line with
existing syntax,
regardless of symbols used.
> > > - It is aligned with the attribute semantics of the majority of C
> > > family languages
> >
> > In what way `#[]` or `@[]` aren't?
>
> The majority of C family languages use `@Attr` without an extra end
> symbol. This makes sense since attributes are simply metadata
> modifying the declaration that follows them, similar to visibility
> and type declarations.
>
> Best regards,
> Theodore
> --
> 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 Thu, Aug 6, 2020 at 12:30 PM Benas IML wrote:
> Hey Theodore,
>
> On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote:
>
> > While none of our syntax options are perfect, I believe @@ has the
> > best long-term tradeoffs because:
> >
> > - It doesn't break useful syntax
>
> Fair enough.
>
> > - It is equally or more concise than grouped attributes without
> > adding complexity to the parser/compiler
>
> Are we really going to debate that ~30 lines of code add complexity?
Hi Benas,
I don't know how many lines of code it will be, since an
implementation for it has never been finished. The patch currently
linked in the RFC does not implement it.
Even if we assume the implementation is only about 30 lines, it's
still extra complexity that I don't understand the benefit of. I
sincerely would like to know what advantage there is of grouped
attributes over the `@@` syntax.
- It is equally or more verbose than `@@` in real-world use cases
- Adding or removing a second attribute with grouping can require
modifying multiple lines, adding unnecessary noise to diffs:
@@SomeAttribute("value")
@@AnotherAttribute("value") # can be added/removed independently
function foo() {}
# vs.
@[SomeAttribute("value")] # changes to:
@[
SomeAttribute("value"),
AnotherAttribute("value"), # not added/removed independently
]
function foo() {}
- How much more added complexity will the grouped syntax require if
we add nested attributes in the future? At the least it will have to
be special-cased in some way, either to disallow grouping for nested
attributes or to treat the grouped syntax the same as an array.
`@@` avoids the need for additional complexity, special cased syntax,
and having to modify extra lines when adding/removing separate
attributes.
> > - It is conceptually closest to the docblock syntax the PHP
> > community is familiar with
>
> Well, if `@@` is similar to `@` (to me it isn't), we can say that
> `@[]` is also similar to `@`.
I would agree that `@[]` is more similar than `#[]` is. But arguably
`@@` is still the closest since docblock annotations don't require
being wrapped in array brackets.
> > - It is aligned with the attribute semantics of the majority of C
> > family languages
>
> In what way `#[]` or `@[]` aren't?
The majority of C family languages use `@Attr` without an extra end
symbol. This makes sense since attributes are simply metadata
modifying the declaration that follows them, similar to visibility
and type declarations.
Best regards,
Theodore
--
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
Hey Theodore,
On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote:
> On Thu, Aug 6, 2020 at 5:24 AM Benas IML
> wrote:
>
> > On Thu, 6 Aug 2020 at 11:45, Rowan Tommins
> wrote:
> >
> > > On Thu, 6 Aug 2020 at 09:12, Benas IML
> wrote:
> > >
> > > > But by sacrificing a few very old codebases (that still use `#` not
> `//`)
> > >
> > > Do you have some basis for # only being used by "very old" codebases?
> As
> > > far as I'm aware, it's not deprecated, and while the PEAR style guide
> > > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
> > >
> > > I agree that it is probably rarer than //... and /*...*/ but let's
> avoid
> > > unnecessary hyperbole.
>
> > A grep search was done by someone in the mailing list in the original
> > `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
> > to be a huge BC or not.
> >
> > Just about all of the matches were either from old codebases or from
> > old PHP 3-5 Metasploit exploits, which are about 5-15 years old.
>
> Hi Benas,
>
> You can look at the grep search here:
> https://grep.app/search?q=%23%5B[lang][0]=PHP
>
> The first BC break in the results is from an automated pentest
> framework repository which was last updated four days ago. So it
> seems like this is still code that is being used.
>
I work myself in the cybersecurity industry and I can tell you 100% that
the automated pentesting tool you're referring to isn't using any of that
`#[` code actively. In fact, over 80% of the code/exploits stored in that
repository don't work with new software/language versions.
That's the whole point - there are hundreds of scripts in numerous
different languages designed for exploiting only specific subset of
software designed for only specific versions of PHP/other languages.
By 5-15 years, I meant the exploits themselves.
Even the current Psalm static analysis tests use # to comment out an
> array:
> https://github.com/vimeo/psalm/blob/afce2dc66ff83ccad3f3a7aa26740a5eb829b2ca/tests/LanguageServer/SymbolLookupTest.php#L453
>
> Not that these individual examples are a big problem, they simply
> illustrate that hash comments are still used in current projects,
> sometimes in ways that the #[] attribute syntax would break.
>
...and that can be fixed within 5 seconds.
`#` comments were even deprecated in PHP's ini files in 5.6.
> When it comes to the @[] alternative, it's harder to grep for actual
> usages, since this string is used in virtually every email validation
> regex. In any case, code like @[foo(), bar()] would no longer work
> without putting a space between the error suppression operator and
> array (which frankly looks pretty confusing):
>
> $x =
> @ [Foo()]; // an array assignment with suppressed warnings
> @[Jit()] // an attribute
> function bar() {}
>
Same goes without saying with `@@` where `@@` means attributes and `@ @`
means double error suppression. Albeit, that is not useful.
> If there were some important language improvement that depended on
> breaking these syntaxes, maybe it would be justified. But so far I
> haven't seen such a justification.
>
> > We are playing probabilities here but at the moment, no one has said
> > any substantial argument why `@@` is better and thus, `@[...]` seems
> > like a better option in the long term.
>
> While none of our syntax options are perfect, I believe @@ has the best
> long-term tradeoffs because:
>
> - It doesn't break useful syntax
>
Fair enough.
- It is equally or more concise than grouped attributes without adding
> complexity to the parser/compiler
>
Are we really going to debate that ~30 lines of code add complexity?
- It offers a clean, simple way to support nested attributes in the
> future if we so desire
>
I'm sorry if I'm not following the conversation but what is blocking that
in `#[]`/`@[]`.
- It is conceptually closest to the docblock syntax the PHP community
> is familiar with
>
Well, if `@@` is similar to `@` (to me it isn't), we can say that `@[]` is
also similar to `@`.
- It is aligned with the attribute semantics of the majority of C
> family languages
>
In what way `#[]` or `@[]` aren't?
> Best regards,
> Theodore
Best regards,
Benas
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Thu, Aug 6, 2020 at 5:24 AM Benas IML wrote:
> On Thu, 6 Aug 2020 at 11:45, Rowan Tommins wrote:
>
> > On Thu, 6 Aug 2020 at 09:12, Benas IML wrote:
> >
> > > But by sacrificing a few very old codebases (that still use `#` not `//`)
> >
> > Do you have some basis for # only being used by "very old" codebases? As
> > far as I'm aware, it's not deprecated, and while the PEAR style guide
> > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
> >
> > I agree that it is probably rarer than //... and /*...*/ but let's avoid
> > unnecessary hyperbole.
> A grep search was done by someone in the mailing list in the original
> `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
> to be a huge BC or not.
>
> Just about all of the matches were either from old codebases or from
> old PHP 3-5 Metasploit exploits, which are about 5-15 years old.
Hi Benas,
You can look at the grep search here:
https://grep.app/search?q=%23%5B[lang][0]=PHP
The first BC break in the results is from an automated pentest
framework repository which was last updated four days ago. So it
seems like this is still code that is being used.
Even the current Psalm static analysis tests use # to comment out an
array:
https://github.com/vimeo/psalm/blob/afce2dc66ff83ccad3f3a7aa26740a5eb829b2ca/tests/LanguageServer/SymbolLookupTest.php#L453
Not that these individual examples are a big problem, they simply
illustrate that hash comments are still used in current projects,
sometimes in ways that the #[] attribute syntax would break.
When it comes to the @[] alternative, it's harder to grep for actual
usages, since this string is used in virtually every email validation
regex. In any case, code like @[foo(), bar()] would no longer work
without putting a space between the error suppression operator and
array (which frankly looks pretty confusing):
$x =
@ [Foo()]; // an array assignment with suppressed warnings
@[Jit()] // an attribute
function bar() {}
If there were some important language improvement that depended on
breaking these syntaxes, maybe it would be justified. But so far I
haven't seen such a justification.
> We are playing probabilities here but at the moment, no one has said
> any substantial argument why `@@` is better and thus, `@[...]` seems
> like a better option in the long term.
While none of our syntax options are perfect, I believe @@ has the best
long-term tradeoffs because:
- It doesn't break useful syntax
- It is equally or more concise than grouped attributes without adding
complexity to the parser/compiler
- It offers a clean, simple way to support nested attributes in the
future if we so desire
- It is conceptually closest to the docblock syntax the PHP community
is familiar with
- It is aligned with the attribute semantics of the majority of C
family languages
Best regards,
Theodore
--
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
> Le 6 août 2020 à 10:11, Benas IML a écrit :
>
> Ending delimiter MAY help us in the future.
>
> I really, really hate all of those arguments stating "that we should care
> only about the present, not the future" and that even though
> `#[...]`/`@[...]` might bring benefits in the future, we should still
> choose `@@`".
>
> This shows clearly that some people are basing their views on subjective
> reasons rather than being objective.
>
> As far as this discussion is going, I see pro-`@@` people just saying
> "Arghhh, let's keep @@, it doesn't bring any benefits that other syntaxes
> do but we don't need them anyways, let's not speculate future".
>
> It's like saying you can either go through door A and get a free car or
> through door B and get the same car and **maybe**, even an additional
> 1,000$.
>
> We are playing probabilities here but at the moment, no one has said any
> substantial argument why `@@` is better and thus, `@[...]` seems like a
> better option in the long term.
>
Note that, in a hypothetical future where the absence of delimiters would lead
to (perceive or real) ambiguity, it will always possible to add optional ones,
as in: `@@simple("thing")` and `@@{very("complex") thing}`.
—Claude
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
A grep search was done by someone in the mailing list in the original `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going to be a huge BC or not. Just about all of the matches were either from old codebases or from old PHP 3-5 Metasploit exploits, which are about 5-15 years old. Best regards, Benas P.S: I accidentally sent this to Rowan only, so forwarding this to the mailing list as well. On Thu, 6 Aug 2020 at 11:45, Rowan Tommins wrote: > > On Thu, 6 Aug 2020 at 09:12, Benas IML wrote: > > > > > But by sacrificing a few very old codebases (that still use `#` not `//`) > > > > > Do you have some basis for # only being used by "very old" codebases? As > far as I'm aware, it's not deprecated, and while the PEAR style guide > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all. > > I agree that it is probably rarer than //... and /*...*/ but let's avoid > unnecessary hyperbole. > > Regards, > -- > Rowan Tommins > [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
On Thu, 6 Aug 2020 at 09:12, Benas IML wrote: > > But by sacrificing a few very old codebases (that still use `#` not `//`) > Do you have some basis for # only being used by "very old" codebases? As far as I'm aware, it's not deprecated, and while the PEAR style guide listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all. I agree that it is probably rarer than //... and /*...*/ but let's avoid unnecessary hyperbole. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Thu, Aug 6, 2020 at 9:18 AM Côme Chilliet < come.chill...@fusiondirectory.org> wrote: > Le Thu, 6 Aug 2020 07:48:05 +0100 (BST), > Derick Rethans a écrit : > > From the RFC: > > - No ending delimiter > > As said before, it does have an ending delimiter when they are arguments > since > there is the parenthesis around them. When there are no arguments I don’t > see > the benefit of an ending delimiter, it’s easy to spot the end of the word. > > > - Doesn't allow grouping > > I do not understand this argument, what is the point of grouping for @@? > Does grouping mean anything special for other syntaxes, or is it just to > save > keystrokes? If it is just to get a more concise syntax when there are > several > attributes, the fact that @@ do not need grouping is a pro, not a con. > > > - No forwards compat with PHP 7 > > But no BC break either, while #[] introduces BC break. > This is **not** true. Both @@ and #[ will break existing PHP 7 code! The question is how likely each of them is. #[ will be slightly higher than @@ - but both will still be in the 0,01% range of occurrences. and for *both* the same Fix is a project wide sed that replaces @@ with @@ and #[ with #[ respectively. > > - Not used ny another language > > @ is used by a lot of other languages, and @@ is the closest we can get in > PHP. > > Côme > > -- > 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 Thu, 6 Aug 2020 at 07:40, Derick Rethans wrote:
> On Wed, 5 Aug 2020, Rowan Tommins wrote:
> > 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.
>
> The syntax that would start it (@@) is not the same, or related to the
> parenthesis that follow the attribut name ( () ). They are not linked,
> as the ( in () is opening a 'context' and the ) in )) is closing it
> again. This is not the ending syntax of '@@'.
>
I'm sorry, I don't understand what you mean here. Are you saying that there
is some practical difference - for parsers, for human readers, or something
else - between the grammars below?
"@@", attribute-name, "(", expression-list, ")"
vs
"@(", attribute-name, "(", expression-list, "))"
Regards,
--
Rowan Tommins
[IMSoP]
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Thu, Aug 6, 2020, 10:18 AM Côme Chilliet < come.chill...@fusiondirectory.org> wrote: > Le Thu, 6 Aug 2020 07:48:05 +0100 (BST), > Derick Rethans a écrit : > > From the RFC: > > - No ending delimiter > > As said before, it does have an ending delimiter when they are arguments > since > there is the parenthesis around them. When there are no arguments I don’t > see > the benefit of an ending delimiter, it’s easy to spot the end of the word. Ending delimiter MAY help us in the future. I really, really hate all of those arguments stating "that we should care only about the present, not the future" and that even though `#[...]`/`@[...]` might bring benefits in the future, we should still choose `@@`". This shows clearly that some people are basing their views on subjective reasons rather than being objective. As far as this discussion is going, I see pro-`@@` people just saying "Arghhh, let's keep @@, it doesn't bring any benefits that other syntaxes do but we don't need them anyways, let's not speculate future". It's like saying you can either go through door A and get a free car or through door B and get the same car and **maybe**, even an additional 1,000$. We are playing probabilities here but at the moment, no one has said any substantial argument why `@@` is better and thus, `@[...]` seems like a better option in the long term. > > - Doesn't allow grouping > > I do not understand this argument, what is the point of grouping for @@? > Does grouping mean anything special for other syntaxes, or is it just to > save > keystrokes? If it is just to get a more concise syntax when there are > several > attributes, the fact that @@ do not need grouping is a pro, not a con. > No, it is not a pro. It's a matter of personal taste. You are basing your opinion on subjective views which goes against this RFC's principles - to choose a syntax that is the best based on the benefits it offers. > - No forwards compat with PHP 7 > > But no BC break either, while #[] introduces BC break. > Not true, technically speaking both `@@` and `#[]` have a BC break. Albeit `@@` has a smaller one. But by sacrificing a few very old codebases (that still use `#` not `//`), we are making sure that we won't run into any parsing problems in the future. And this is far more important. > - Not used ny another language > > @ is used by a lot of other languages, and @@ is the closest we can get in > PHP. > This is a pointless argument. `[...]`/`[[...]]` is also used by a lot of languages, `#[...]` and `@[...]` is the closest we can get to that. Heck, `@[...]` is the closest to both `@` and `[...]`. Best regards, Benas >
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Thu, 6 Aug 2020 at 08:18, Côme Chilliet < come.chill...@fusiondirectory.org> wrote: > As said before, it does have an ending delimiter when they are arguments > since > there is the parenthesis around them. When there are no arguments I don’t > see > the benefit of an ending delimiter, it’s easy to spot the end of the word. > And if needed, make the parenthesis required. So @@Foo is illegal, but @@Foo() is allowed. Required parenthesis is familiar to most PHP programmers (functions, classes following common coding conventions) - what's not to like? Using "^" in the code demonstrations below as no one has proposed it and my point isn't about #, << or @@ we get: ^Foo( ^Bar(43, "raa") ) vs ^[Foo( ^[Bar(43, "raa")] )] To me the former is significantly more pleasant to read. Is it difficult to parse? Peter
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Le Thu, 6 Aug 2020 07:48:05 +0100 (BST), Derick Rethans a écrit : > From the RFC: > - No ending delimiter As said before, it does have an ending delimiter when they are arguments since there is the parenthesis around them. When there are no arguments I don’t see the benefit of an ending delimiter, it’s easy to spot the end of the word. > - Doesn't allow grouping I do not understand this argument, what is the point of grouping for @@? Does grouping mean anything special for other syntaxes, or is it just to save keystrokes? If it is just to get a more concise syntax when there are several attributes, the fact that @@ do not need grouping is a pro, not a con. > - No forwards compat with PHP 7 But no BC break either, while #[] introduces BC break. > - Not used ny another language @ is used by a lot of other languages, and @@ is the closest we can get in PHP. Côme -- 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 Wed, 5 Aug 2020, Rowan Tommins wrote: > 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. Hear hear. 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, Theodore Brown wrote:
>
> #[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")
Shall I do one where we count pixels? Because @@ is using a lot more of
them... And there is also no reason why it can't be just:
@[AttrWithParam("foobar")]
@[SomeOtherAttr("fizzbuzz")]
Although group is allowed, it doesn't mean it's always useful to do.
@@Attr1 @@Attr2
Seems to me like a cat had trespassed on your keyboard, the *heavy* @@
also dominates the line.
> 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.
>From the RFC:
- No ending delimiter
- Doesn't allow grouping
- No forwards compat with PHP 7
- Not used ny another language
And the "familiar with docblocks" is quite a stretch, as that doesn't
use @@ either. I've only included it because it would be unfair if @@
had nothing positive going for it.
cheers,
Derick
--
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 Wed, 5 Aug 2020, Rowan Tommins wrote: > 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. The syntax that would start it (@@) is not the same, or related to the parenthesis that follow the attribut name ( () ). They are not linked, as the ( in () is opening a 'context' and the ) in )) is closing it again. This is not the ending syntax of '@@'. 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 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
>
>
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Hi Theodore, > I meant to say "statement", e.g. > I suspect it is a statement and not an optional piece of data on a > statement, like say `public`. I assume this would boil down to a disagreement on what we mean by statement, and could be clarified by using whatever that definition was instead of "statement" or "declaration". For example, I might broadly mean that there are expressions, statements, and statement lists in PHP, and statements can be a certain list of node types composed of statements/expressions/nodes (plus standalone expressions), expressions can contain expressions or statement lists, but not statements. (and statement lists can contain 0 or more statements) (e.g. closures are expressions) - And then there are nodes that are parts of statements/expressions but neither statements nor expressions, such as parameter declarations - The php language specification is more complicated than that and my definition would inevitably be over-simplifying, the definition I'd meant was https://github.com/php/php-langspec/blob/master/spec/11-statements.md By statement, I'd be referring to what parsers generally categorize as statements. For example, the list of nodes in https://github.com/nikic/PHP-Parser/tree/master/lib/PhpParser/Node/Stmt - This has changed in the past, e.g. the "throw expression" RFC. - Still, I'd believe the attributes would be metadata associated with a class statement, a method/function statement, a parameter node, or a closure declaration expression Regards, - Tyson -- 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 8:59 PM 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`. I meant to say "statement", e.g. I suspect it is a statement and not an optional piece of data on a statement, like say `public`. -- 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
> 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`. -- 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
Hi Derick,
> 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]
>
> 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.
>
> Kind regards,
> Theodore
I agree with Theodore's points, including that this is metadata on a
declaration, not a declaration itself.
This RFC has proposed that the lack of a closing delimiter might get in the way
of future language changes,
but has not given examples of hypothetical syntax extensions that would cause
future conflict
and that it'd be impossible to resolve/avoid the ambiguity.
(e.g. Java has managed with `@AttributeName` and optional arguments in
parameters, classes, properties, methods, etc.)
PHP already has a lot of places where there is no closing delimiter, even where
you'd want/expect one,
so I wouldn't call a lack of closing delimiter unique.
e.g. the below example is parsed as `clone((new stdClass())->foo)`,
because parenthesis aren't part of `clone`.
```
php > clone(new stdClass())->foo;
Notice: Undefined property: stdClass::$foo in php shell code on line 1
Warning: Uncaught Error: __clone method called on non-object in php shell code:1
```
Thanks,
- Tyson
--
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
Hi Derick,
> 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.
1. I feel like "Changes the lexing of **remaining** tokens" should also be
included in the table following it - that's a major difference between
`#[`(Yes) and each of the other proposals (No).
The last time a substantial lexing change (that affected the following
tokens, not just the tokens in question) happened was
https://wiki.php.net/rfc/flexible_heredoc_nowdoc_syntaxes , but flexible
heredoc is rare in practice and a project using it would almost always need to
drop support for 7.2.
I expect attributes to be used much, much more frequently than flexible
heredoc, and to break in subtler ways.
Projects such as php-parser would be affected by the change to lexing, and
would either have to force users to specify the php major version or to always
emulate 8.0's lexing if `#[` was encountered in a T_COMMENT token.
My earlier objections to `#[` were
https://externals.io/message/111218#111239
To add to that, the benefit of forwards compatibility is also a drawback in
some ways for the next few years (or longer, if you include OSes that
unofficially backport security patches)
A developer running php7 could run `php --syntax-check` locally on a file
containing attributes
and assume it'd work in php 8 when deployed to a php 8 environment or when
publishing a library to packagist.
(e.g. `#[DeprecationReason('This won't work because X')]` has a single
quote after `won` terminating a string literal, resulting in a parse error only
affecting php 8)
Better tooling would help to avoid that, but better tooling isn't universal.
2. This RFC mentions objections to `@@` but not objections to other syntaxes.
Summarizing/Linking the main arguments for/against all 4+ proposed syntaxes
in an appendix of the RFC (with some reasonable length limit) would help in
making an informed vote.
There have been over 50 emails so far in
https://externals.io/message/111300 and https://externals.io/message/111312
Thanks,
- Tyson
--
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
Hi all, > On Aug 4, 2020, at 17:07, 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. As it was the case > with https://wiki.php.net/rfc/shorter_attribute_syntax, it had a primary > vote asking "Are you okay with re-voting on the attribute syntax for PHP > 8.0?" and that vote passed with 50 to 8. > > The primary vote on this RFC could be the exact same question, but I > believe the primary vote needs to be there. Without this primary vote, we > could be enacting a change that only (with 4 options) 25%+1 voters support, > which is clearly insufficient. However, if 2/3 of the voters agree that > something needs to change, they are also accepting that the change may not > be the one they prefer. Hear, hear. If this RFC *must* go to a vote (and that is not a given), then adding a primary vote along the lines of "Are you okay with re-voting on the attribute syntax for PHP 8.0?" would go a long way toward alleviating the "vote until the voters get it 'right'" problem. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Hi Derick, 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. As it was the case with https://wiki.php.net/rfc/shorter_attribute_syntax, it had a primary vote asking "Are you okay with re-voting on the attribute syntax for PHP 8.0?" and that vote passed with 50 to 8. The primary vote on this RFC could be the exact same question, but I believe the primary vote needs to be there. Without this primary vote, we could be enacting a change that only (with 4 options) 25%+1 voters support, which is clearly insufficient. However, if 2/3 of the voters agree that something needs to change, they are also accepting that the change may not be the one they prefer. >From the voting RFC (https://wiki.php.net/RFC/voting#required_majority): "The primary vote of an RFC, determining overall acceptance of the proposal, may only have two voting options and requires a 2/3 majority. This means that the number of Yes votes must be greater than or equal to the number of No votes multiplied by two." On the same RFC we can also find information about the format of secondary votes which mandates a simple majority, this should disqualify STV: "Additionally, an RFC may have secondary votes, which are used to decide implementation details. Such votes may have more than two voting options and may be decided by simple plurality. This means that the voting option with the most votes wins. If there are multiple options with the most number of votes, it is left at the discretion of the RFC author to choose one of them." I'm not saying that I agree or disagree with the changes you propose, but I think that all RFCs should follow the rules that are laid out. Those rules were last changed by an RFC which also required a 2/3 majority ( https://wiki.php.net/rfc/abolish-narrow-margins), so if you want to change the requirements to accept an RFC, you should propose them and they should be accepted before proposing a RFC which does not abide to these requirements. Regards, Pedro On Tue, Aug 4, 2020 at 2:45 PM Derick Rethans wrote: > Hi, > > 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. > > FWIW, this has an excemption from the RM Sara as per [2]: > > > * Shorter Attribute Syntax Change > >- Joe/Derick - Please make sure this RFC moves along and reaches > > conclusion by beta3, as discussed previously. > > > cheers, > Derick > > [1] https://externals.io/message/111218#111261 > [2] https://externals.io/message/111286#111286 > > -- > 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 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]
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.
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
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, 4 Aug 2020, Sara Golemon wrote: > On Tue, Aug 4, 2020 at 9:03 AM Benjamin Eberlei wrote: > > > It provides a small BC break where code written as @[$foo, $bar] = > > baz(); or $foo = @["bar" => $baz]; will not compile on PHP 8 > > anymore, but that can be easily fixed by writing it with a space > > between @ and [. > > > If those are the potential breaks we're choosing between, I would > favor #[...] as it provides strong forward-compatibility to drive > adoption and use at the cost of a parse error that's easily fixed > (even programmatically with a very simple script). @[...] provides no > forward compat with a roughly equal chance of easily fixed syntax > break. > > Given that, the choice seems obvious to me. Change my mind? I pretty much agree, but @[ … ] is there as a compromise as it does show some fmailiarity with the already existing @ in doc blocks. 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 04/08/2020 16:19, Sebastian Bergmann wrote: Am 04.08.2020 um 15:45 schrieb Derick Rethans: https://wiki.php.net/rfc/shorter_attribute_syntax_change This is probably a wiki/markup issue: the RFC shows "«Attr»" instead of "<>" for the original syntax. Given that every single thread about attributes contains an email like the above, no matter what we end up with I will be glad if it's not <>. Best, Jordi -- Jordi Boggiano @seldaek - https://seld.be -- 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 9:03 AM Benjamin Eberlei wrote: > It provides a small BC break where code written as @[$foo, $bar] = baz(); > or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that can > be easily > fixed by writing it with a space between @ and [. > > If those are the potential breaks we're choosing between, I would favor #[...] as it provides strong forward-compatibility to drive adoption and use at the cost of a parse error that's easily fixed (even programmatically with a very simple script). @[...] provides no forward compat with a roughly equal chance of easily fixed syntax break. Given that, the choice seems obvious to me. Change my mind? -Sara
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues wrote: > Suggestions: > > $(Attribute()) (available) > $[Attribute()] (available) > <> 2)>> (like strings escapes) > I had someone else suggest $[] to me today as well, funny coincidence :-) Can you take the "@@ to @[] pull" request as a starting point to try if this works with a patch? https://github.com/php/php-src/pull/5928 This syntax is "not" familiar with docblock usage of @, as it doesn't contain a @ :-D It does pose difficulty for static analyers and userland parsers, because they see the $ as a T_VARIABLE in PHP 7. > About $() syntax: > >- Number of required characters: (2+1) >- Has end delimiter: yes >- Allow grouping: yes >- Forward compatibility in PHP 7: yes >- Breaks BC of valid PHP 7 codes: no >- Used by other languages: no? >- Familiar with Docblock Usage: I don't know >- Difficulties with Userland Parsers: I don't know > > And my another suggestion is use a more verbose for now, until we have a > good consensus about it "using attribute()": > > >- Number of required characters: (16+1) > > >- Has end delimiter: yes > > >- Allow grouping: yes > > >- Forward compatibility in PHP 7: yes > > >- Breaks BC of valid PHP 7 codes: no > > >- Used by other languages: no? > > >- Familiar with Docblock Usage: I don't know > > >- Difficulties with Userland Parsers: I don't know > > This would definitely need a fully working patch to be a contender in the vote. - It's not forward compatibltle with PHP 7, because use of the syntax would lead to a fatal error on PHP 7 parsers or am I seeing something wrong? - its not a familiar syntax for PHP developers used to @ in docblocks > > Atenciosamente, > David Rodrigues > > > Em ter., 4 de ago. de 2020 às 11:03, Benjamin Eberlei > escreveu: > >> On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote: >> >> > Hi, >> > >> > 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. >> > >> > FWIW, this has an excemption from the RM Sara as per [2]: >> > >> > > * Shorter Attribute Syntax Change >> > >- Joe/Derick - Please make sure this RFC moves along and reaches >> > > conclusion by beta3, as discussed previously. >> > >> >> In combination to the existing proposals we already voted one, this RFC >> includes a fourth option that has not been discussed before, >> and could be the compromise we are all looking for :-) >> >> @[Attr] combines both the with to use the familiar @ of many, and the wish >> to have a closing symbol/termination symbol that many others have. >> >> It does not have the downsides that Tyson found w.r.t. to #[Attr] being >> interpreted as comment on PHP 7, but that also means its not forward >> compatible like #[Attr] is. >> >> It provides a small BC break where code written as @[$foo, $bar] = baz(); >> or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that >> can >> be easily >> fixed by writing it with a space between @ and [. >> >> >> > >> > cheers, >> > Derick >> > >> > [1] https://externals.io/message/111218#111261 >> > [2] https://externals.io/message/111286#111286 >> > >> > -- >> > 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 4:19 PM David Rodrigues wrote: > Suggestions: > > $(Attribute()) (available) > $[Attribute()] (available) > <> 2)>> (like strings escapes) > The syntax for the first two seems oddly pleasing when used within PHP.
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Suggestions: $(Attribute()) (available) $[Attribute()] (available) <> 2)>> (like strings escapes) About $() syntax: - Number of required characters: (2+1) - Has end delimiter: yes - Allow grouping: yes - Forward compatibility in PHP 7: yes - Breaks BC of valid PHP 7 codes: no - Used by other languages: no? - Familiar with Docblock Usage: I don't know - Difficulties with Userland Parsers: I don't know And my another suggestion is use a more verbose for now, until we have a good consensus about it "using attribute()": - Number of required characters: (16+1) - Has end delimiter: yes - Allow grouping: yes - Forward compatibility in PHP 7: yes - Breaks BC of valid PHP 7 codes: no - Used by other languages: no? - Familiar with Docblock Usage: I don't know - Difficulties with Userland Parsers: I don't know Atenciosamente, David Rodrigues Em ter., 4 de ago. de 2020 às 11:03, Benjamin Eberlei escreveu: > On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote: > > > Hi, > > > > 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. > > > > FWIW, this has an excemption from the RM Sara as per [2]: > > > > > * Shorter Attribute Syntax Change > > >- Joe/Derick - Please make sure this RFC moves along and reaches > > > conclusion by beta3, as discussed previously. > > > > In combination to the existing proposals we already voted one, this RFC > includes a fourth option that has not been discussed before, > and could be the compromise we are all looking for :-) > > @[Attr] combines both the with to use the familiar @ of many, and the wish > to have a closing symbol/termination symbol that many others have. > > It does not have the downsides that Tyson found w.r.t. to #[Attr] being > interpreted as comment on PHP 7, but that also means its not forward > compatible like #[Attr] is. > > It provides a small BC break where code written as @[$foo, $bar] = baz(); > or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that can > be easily > fixed by writing it with a space between @ and [. > > > > > > cheers, > > Derick > > > > [1] https://externals.io/message/111218#111261 > > [2] https://externals.io/message/111286#111286 > > > > -- > > 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
Am 04.08.2020 um 15:45 schrieb Derick Rethans: https://wiki.php.net/rfc/shorter_attribute_syntax_change This is probably a wiki/markup issue: the RFC shows "«Attr»" instead of "<>" for the original syntax. -- 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
Hi,
Am 04.08.20 um 15:45 schrieb Derick Rethans:
> Patches and comments welcome.
if the syntax will be changed to having a closing delimiter, I would
really like to have symmetrical delimiters, like @{ }@ or something like
that. ] as a closing delimiter just seems to collide with the array
syntax and does not provide much parsing benefit to me.
Greets
Dennis
--
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 3:46 PM Derick Rethans wrote: > Hi, > > 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. > > FWIW, this has an excemption from the RM Sara as per [2]: > > > * Shorter Attribute Syntax Change > >- Joe/Derick - Please make sure this RFC moves along and reaches > > conclusion by beta3, as discussed previously. > In combination to the existing proposals we already voted one, this RFC includes a fourth option that has not been discussed before, and could be the compromise we are all looking for :-) @[Attr] combines both the with to use the familiar @ of many, and the wish to have a closing symbol/termination symbol that many others have. It does not have the downsides that Tyson found w.r.t. to #[Attr] being interpreted as comment on PHP 7, but that also means its not forward compatible like #[Attr] is. It provides a small BC break where code written as @[$foo, $bar] = baz(); or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that can be easily fixed by writing it with a space between @ and [. > > cheers, > Derick > > [1] https://externals.io/message/111218#111261 > [2] https://externals.io/message/111286#111286 > > -- > 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
A little nitpick but I don't think that `@@` really signals familiarity with docblocks. Nevertheless, I really like `@[...]`. I think it combines best of the both worlds (little-to-no BC breaks, ending delimiter, etc.) and also looks aesthetically pleasing. Best regards, Benas On Tue, Aug 4, 2020, 4:45 PM Derick Rethans wrote: > Hi, > > 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. > > FWIW, this has an excemption from the RM Sara as per [2]: > > > * Shorter Attribute Syntax Change > >- Joe/Derick - Please make sure this RFC moves along and reaches > > conclusion by beta3, as discussed previously. > > > cheers, > Derick > > [1] https://externals.io/message/111218#111261 > [2] https://externals.io/message/111286#111286 > > -- > 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 > >
