Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Le Tue, 28 Jul 2020 17:57:34 +, Theodore Brown a écrit : > Rust chose to use #[] even though it wasn't used by any other language. > Does that make it a bad fit for Rust? No. But just because Rust uses > a syntax also doesn't mean it's a good fit for PHP. For those which like me do not know Rust, I checked and it appears that "#" is only used for attributes in Rust, and is not a comment starter. So that explains why it makes sense for Rust to use this. But it still feels like a really bad idea to me to mix comment and code in PHP. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Sun, Aug 2, 2020 at 4:40 PM Dan Ackroyd wrote: > Theodore Brown wrote: > > > > The Shorter Attribute Syntax RFC explicitly mentioned that the @@ > > syntax would supersede the grouped attributes proposal: [1] > > From the RFC: > > > > # Unaffected Functionality > > ...it will supersede the syntax for grouped attributes. > > I missed that change at least in part because it's listed under > "unaffected functionality". > > Even reading it now, it's not obvious that "superseded" means "grouped > attributes won't be supported". Hi Dan, I'm not sure it can really be called a change, since at the time the Shorter Attribute Syntax RFC went to vote the Attribute Amendments RFC had not yet been accepted (and it certainly wasn't clear whether the grouped attribute proposal would pass). Anyway, the whole point of the grouped attribute syntax was to alleviate some of the verbosity of the << and >> tokens when adding multiple attributes. The @@ syntax supersedes, or replaces grouped attributes since in real-world use cases it is even less verbose than the grouped attribute proposal, [1] while avoiding its additional implementation complexity. Kind regards, Theodore [1]: https://externals.io/message/110355#110414 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Sun, Aug 2, 2020 at 10:11 AM Derick Rethans wrote: > On Thu, 30 Jul 2020, Benjamin Eberlei wrote: > > > I think it has become clear that we need to revisit this syntax question > > again, including the elephpant in the room of delaying this feature to > 8.1. > > > > The reason is not only Joe's desire to revote on #[], but also that there > > are now more syntax proposals such as @[] by Derick or @@ in comments by > > Tyson (though no patch exists for it yet). At this point a lot of > syntaxes > > are potentially viable (except single @, please don't suggest it). > > > > I feel the choice between many syntaxes is 80% subjective, 20% objective > > facts, so tensions are to be expected. > > > > As the author of the original RFC and patch, I hope I have some klout in > > suggesting the following procedure (RMs would need to extend their > approval > > for revote to this). > > This seems like a sensible solution. > > cheers, > Derick > Sounds good to me as well. I'll update this RFC to Declined. Thanks, everyone for the discussion and everyone who reviewed the RFC and gave feedback on ideas and code examples. -- - Joe Ferguson JoeFerguson.me osmihelp.org
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Theodore Brown wrote: > > The Shorter Attribute Syntax RFC explicitly mentioned that the @@ > syntax would supersede the grouped attributes proposal: [1] >From the RFC: > > # Unaffected Functionality > ...it will supersede the syntax for grouped attributes. I missed that change at least in part because it's listed under "unaffected functionality". Even reading it now, it's not obvious that "superseded" means "grouped attributes won't be supported". cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Sun, Aug 2, 2020 at 10:06 AM Derick Rethans wrote: > On Wed, 29 Jul 2020, Benjamin Eberlei wrote: > > > Personally I favor #[] myself, but there has been a vote with a > > substantial participation choosing @@. Overturning this democratic > > outcome should require **significant** technical arguments, otherwise > > this RFC would provide problematic precedent for any RFC to be > > overturned by arbitrary revoting. > > > > The arguments the RFC brings forward don't convince me that we should > > pick #[] over @@. > > However, one other thing just came to light where the "Shorter Syntax" > RFC was unclear about: no longer supporting grouping. > > Changing the accepted << .. >> syntax breaks something that > was accepted through "Attribute Amendments": grouping, as per > https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes > > The switch to @@ does now not allow for this, but we haven't spefically > voted on we wanted to get rid of grouping. The Shorter Syntax RFC does > talk about it in "Verbosity" > (https://wiki.php.net/rfc/shorter_attribute_syntax#verbosity), but > that's not a technical reason, just opinion about readability. Hi Dereck, The Shorter Attribute Syntax RFC explicitly mentioned that the @@ syntax would supersede the grouped attributes proposal: [1] > this proposal does not conflict with the Attribute Amendments RFC, > with the exception that if the @@ syntax is accepted, it will > supersede the syntax for grouped attributes. This was also documented in the Attribute Amendments RFC itself: [2] > This feature would be superseded by any other RFC getting accepted > that changes the syntax. I agree with Benjamin that the democratic outcome of the vote between <<>>, @@, and #[] should not be overturned unless there is a serious technical problem with the implementation, otherwise we set precedent for someone to overturn any RFC by arbitrarily re-voting until they get the result they want. Best regards, Theodore [1]: https://wiki.php.net/rfc/shorter_attribute_syntax#unaffected_functionality [2]: https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Thu, 30 Jul 2020, Benjamin Eberlei wrote: > I think it has become clear that we need to revisit this syntax question > again, including the elephpant in the room of delaying this feature to 8.1. > > The reason is not only Joe's desire to revote on #[], but also that there > are now more syntax proposals such as @[] by Derick or @@ in comments by > Tyson (though no patch exists for it yet). At this point a lot of syntaxes > are potentially viable (except single @, please don't suggest it). > > I feel the choice between many syntaxes is 80% subjective, 20% objective > facts, so tensions are to be expected. > > As the author of the original RFC and patch, I hope I have some klout in > suggesting the following procedure (RMs would need to extend their approval > for revote to this). This seems like a sensible solution. 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] [Discussion] Shorter Attribute Syntax Change
On Wed, 29 Jul 2020, Benjamin Eberlei wrote: > Personally I favor #[] myself, but there has been a vote with a > substantial participation choosing @@. Overturning this democratic > outcome should require **significant** technical arguments, otherwise > this RFC would provide problematic precedent for any RFC to be > overturned by arbitrary revoting. > > The arguments the RFC brings forward don't convince me that we should > pick #[] over @@. However, one other thing just came to light where the "Shorter Syntax" RFC was unclear about: no longer supporting grouping. Changing the accepted << .. >> syntax breaks something that was accepted through "Attribute Amendments": grouping, as per https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes The switch to @@ does now not allow for this, but we haven't spefically voted on we wanted to get rid of grouping. The Shorter Syntax RFC does talk about it in "Verbosity" (https://wiki.php.net/rfc/shorter_attribute_syntax#verbosity), but that's not a technical reason, just opinion about readability. 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] [Discussion] Shorter Attribute Syntax Change
HI, [disclosure: I'm not php internals/interpreter developer; have ~10 years of using php language] I've searched but couldn't find in this discussion: Can we keep the 'current' [doctrine/annotations or similar libraries] annotation syntax and implement parsing of metadata in PHPinterpreter? [something like having internal/native doctrine/annotations implementation that can use opcache] pros: - existing tooling will continue to work - existing code will continue to work - no need for developers to migrate their code - no need for developers to learn new syntax cons: - code comments cannot be removed from opcache :| [or can they? if metadata/annotations get parsed and attached in preload - comments can be discarded if not needed in runtime] I'm sorry if I've added some noise by missing something that's obvious; I would really appreciate it if someone from the php internal comments on this. cheers, k On Thu, Jul 30, 2020 at 7:24 PM tyson andre wrote: > Hi Joe Ferguson, > > > Now that it seems the technical concerns around @@ have been resolved by > > another pending, passing, RFC, I'm still here wanting us to talk about > the > > impact of @@ on static analysis tools. Apparently, internals doesn't care > > about these projects. I care and I'm trying to help. I'm not trying to > > revote until I get the vote I want. I'm just a dude that had some free > time > > while on vacation when he saw a chance to contribute. > > 3 commonly used static analyzers (for type inference) are > - PHPStan and Psalm, both of which use nikic/php-parser. As Nikita Popov > (the maintainer of php-parser) wrote, > > > Emulating #[] lexing on older versions will > > definitely be a challenge for PHP-Parser. I don't think we should make > > concerns of external tooling hold us back too much, but the phpcs > argument > > really doesn't hold water. > > Comparatively, it would be easy to join two adjacent `@` tokens to a > single `@@` token in a single pass over token_get_all. > Parsers would likely already do that or benefit from doing that for tokens > such as the `match` token (T_MATCH) in php 8.0. > > Another commonly used static analyzer is Phan ( > https://github.com/phan/phan/) , which I am a maintainer of. > My reasons for preferring `<<>>` or @@ over `#[` were mentioned in > https://externals.io/message/111218#111239 . > > For phpcs and other linters, my belief is that this might be easier for > simple use cases in the short term, > but edge cases or ambiguities like multi-line attributes or refactorings > that were safe in php 7 > (such as moving `#[]` behind other tokens to another line) > may cause issues for users of those tools (until those tools drop support > for php 7.x and older). > This is why I'd advocate for a distinct token that doesn't overlap with > line comments > > Cheers, > - Tyson > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi Joe Ferguson, > Now that it seems the technical concerns around @@ have been resolved by > another pending, passing, RFC, I'm still here wanting us to talk about the > impact of @@ on static analysis tools. Apparently, internals doesn't care > about these projects. I care and I'm trying to help. I'm not trying to > revote until I get the vote I want. I'm just a dude that had some free time > while on vacation when he saw a chance to contribute. 3 commonly used static analyzers (for type inference) are - PHPStan and Psalm, both of which use nikic/php-parser. As Nikita Popov (the maintainer of php-parser) wrote, > Emulating #[] lexing on older versions will > definitely be a challenge for PHP-Parser. I don't think we should make > concerns of external tooling hold us back too much, but the phpcs argument > really doesn't hold water. Comparatively, it would be easy to join two adjacent `@` tokens to a single `@@` token in a single pass over token_get_all. Parsers would likely already do that or benefit from doing that for tokens such as the `match` token (T_MATCH) in php 8.0. Another commonly used static analyzer is Phan (https://github.com/phan/phan/) , which I am a maintainer of. My reasons for preferring `<<>>` or @@ over `#[` were mentioned in https://externals.io/message/111218#111239 . For phpcs and other linters, my belief is that this might be easier for simple use cases in the short term, but edge cases or ambiguities like multi-line attributes or refactorings that were safe in php 7 (such as moving `#[]` behind other tokens to another line) may cause issues for users of those tools (until those tools drop support for php 7.x and older). This is why I'd advocate for a distinct token that doesn't overlap with line comments Cheers, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Thu, Jul 30, 2020 at 12:30 PM Rowan Tommins wrote: > > On Thu, 30 Jul 2020 at 17:18, guilhermebla...@gmail.com < > guilhermebla...@gmail.com> wrote: > > > > > I bet a search/replace wouldn't be that hard to be achieved > > > > > Find-and-replace always sounds like a good idea, until you realise that > people run *a lot* of third-party code. I would not enjoy going through > every Composer package in my vendor directory, checking for or supplying an > appropriate patch, and then waiting for a tag or forking to create my own. The beauty is that maintainers could release the packages today, and not wait for 8.0.0 to be released. > > Regards, > -- > Rowan Tommins > [IMSoP] -- Guilherme Blanco SVP Technology at Statflo Inc. Mobile: +1 647 232 5599 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Thu, 30 Jul 2020 at 17:18, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > > I bet a search/replace wouldn't be that hard to be achieved > Find-and-replace always sounds like a good idea, until you realise that people run *a lot* of third-party code. I would not enjoy going through every Composer package in my vendor directory, checking for or supplying an appropriate patch, and then waiting for a tag or forking to create my own. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Thu, Jul 30, 2020 at 6:19 PM guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Question: The key factor of not using @ is due to conflict of > suppression symbol. > While we are in a major (where BC breaks are not encourage, but > tolerable), have we considered the possibility of BC breaking > suppression symbol (@ would become @@) and using @ for Attributes? > no chance, it needs at lesat 1 major release of deprecation before a syntax should be reusable for something else. > > I bet a search/replace wouldn't be that hard to be achieved, and it > would function even today (as @@ is acceptable). Basically, it's a BC > break where code needs to be changed, but backwards compatible as new > suppressor symbol is backwards compatible with previous versions of > PHP. > > Just some food for thought > > On Thu, Jul 30, 2020 at 11:57 AM Rowan Tommins > wrote: > > > > On Thu, 30 Jul 2020 at 14:28, Joe Ferguson wrote: > > > > > ... I'm still here wanting us to talk about the > > > impact of @@ on static analysis tools. Apparently, internals doesn't > care > > > about these projects. > > > > > > > > > I don't think that's a reasonable summary of this thread at all. I've > seen > > three main types of response: > > > > 1) "I haven't followed the discussion about PHPCS, please could you > > summarise the problem." > > 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x > > syntax." > > 3) "I think #[] will cause as many problems for such tools as @@, just in > > different places." > > > > Maybe they weren't always as polite or succinct as that, but not agreeing > > with you is not the same as not caring. > > > > > > As far as I can make out, attributes that appear entirely on a single > line > > with no other text are trivial to ignore in any parser whatever the > syntax. > > That trivial case is slightly more trivial with #[] because a PHP 7 > parser > > will treat it as a line comment; but add a rule to your parser to also > > treat "@@" as a line comment, and you're done. > > > > The problems come when you have a) an attribute definition spanning > > multiple lines, and/or b) an attribute definition inline with other code. > > As soon as you have that, you have no choice but to parse the code > entirely > > according to the grammar of PHP 8, not as "PHP 7 with some warts". > > > > If detecting the end of annotation tokens is really that difficult, would > > it suffice to make the () mandatory (i.e. @@Deprecated() rather than > > @@Deprecated)? The rules for what could appear between @@ and ( are > pretty > > simple, and finding the correct ending ) should be pretty much the same > > effort as finding the correct ending ], since both can occur in matching > > pairs inside the argument list. > > > > Regards, > > -- > > Rowan Tommins > > [IMSoP] > > > > -- > Guilherme Blanco > SVP Technology at Statflo Inc. > Mobile: +1 647 232 5599 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Question: The key factor of not using @ is due to conflict of suppression symbol. While we are in a major (where BC breaks are not encourage, but tolerable), have we considered the possibility of BC breaking suppression symbol (@ would become @@) and using @ for Attributes? I bet a search/replace wouldn't be that hard to be achieved, and it would function even today (as @@ is acceptable). Basically, it's a BC break where code needs to be changed, but backwards compatible as new suppressor symbol is backwards compatible with previous versions of PHP. Just some food for thought On Thu, Jul 30, 2020 at 11:57 AM Rowan Tommins wrote: > > On Thu, 30 Jul 2020 at 14:28, Joe Ferguson wrote: > > > ... I'm still here wanting us to talk about the > > impact of @@ on static analysis tools. Apparently, internals doesn't care > > about these projects. > > > > > I don't think that's a reasonable summary of this thread at all. I've seen > three main types of response: > > 1) "I haven't followed the discussion about PHPCS, please could you > summarise the problem." > 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x > syntax." > 3) "I think #[] will cause as many problems for such tools as @@, just in > different places." > > Maybe they weren't always as polite or succinct as that, but not agreeing > with you is not the same as not caring. > > > As far as I can make out, attributes that appear entirely on a single line > with no other text are trivial to ignore in any parser whatever the syntax. > That trivial case is slightly more trivial with #[] because a PHP 7 parser > will treat it as a line comment; but add a rule to your parser to also > treat "@@" as a line comment, and you're done. > > The problems come when you have a) an attribute definition spanning > multiple lines, and/or b) an attribute definition inline with other code. > As soon as you have that, you have no choice but to parse the code entirely > according to the grammar of PHP 8, not as "PHP 7 with some warts". > > If detecting the end of annotation tokens is really that difficult, would > it suffice to make the () mandatory (i.e. @@Deprecated() rather than > @@Deprecated)? The rules for what could appear between @@ and ( are pretty > simple, and finding the correct ending ) should be pretty much the same > effort as finding the correct ending ], since both can occur in matching > pairs inside the argument list. > > Regards, > -- > Rowan Tommins > [IMSoP] -- Guilherme Blanco SVP Technology at Statflo Inc. Mobile: +1 647 232 5599 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Thu, 30 Jul 2020 at 14:28, Joe Ferguson wrote: > ... I'm still here wanting us to talk about the > impact of @@ on static analysis tools. Apparently, internals doesn't care > about these projects. > I don't think that's a reasonable summary of this thread at all. I've seen three main types of response: 1) "I haven't followed the discussion about PHPCS, please could you summarise the problem." 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x syntax." 3) "I think #[] will cause as many problems for such tools as @@, just in different places." Maybe they weren't always as polite or succinct as that, but not agreeing with you is not the same as not caring. As far as I can make out, attributes that appear entirely on a single line with no other text are trivial to ignore in any parser whatever the syntax. That trivial case is slightly more trivial with #[] because a PHP 7 parser will treat it as a line comment; but add a rule to your parser to also treat "@@" as a line comment, and you're done. The problems come when you have a) an attribute definition spanning multiple lines, and/or b) an attribute definition inline with other code. As soon as you have that, you have no choice but to parse the code entirely according to the grammar of PHP 8, not as "PHP 7 with some warts". If detecting the end of annotation tokens is really that difficult, would it suffice to make the () mandatory (i.e. @@Deprecated() rather than @@Deprecated)? The rules for what could appear between @@ and ( are pretty simple, and finding the correct ending ) should be pretty much the same effort as finding the correct ending ], since both can occur in matching pairs inside the argument list. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
I think that verbosity is not a problem if compared to "strange mixed
symbols", mainly to new users. Google it is a bit hard "what means double
at". And "using attribute" is very clear.
Anyway, I think that is valid we use it for now until we have a good symbol
arrangement, and on future we could have the "verbose syntax" ("using
attribute()") and shortened syntax (to be decided, but like "#[...]").
Atenciosamente,
David Rodrigues
Em qui., 30 de jul. de 2020 às 11:09, tyson andre
escreveu:
> Hi David,
>
> > I would like to suggests the syntax "using attribute(Attribute, ...)". It
> > is more clear and should not create BC.
>
> I'd agree that it's implementable and works with the tokenizer.
>
> My main objection is the verbosity, which is the reason I assume many
> other languages have fairly short/distinct attribute syntax.
>
> ```
> // Assume Unused tells IDEs/analyzers/linters not to warn about unused
> parameters,
> // and Override warns about a method not being an override
>
> using attribute(Override)
> public function apiMethod(
> using attribute(Unused)
> array $params,
> using attribute(Unused)
> bool $featureEnabled,
> using attribute(Unused)
> array $options,
> ) {...}
> ```
>
> - Tyson
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi David,
> I would like to suggests the syntax "using attribute(Attribute, ...)". It
> is more clear and should not create BC.
I'd agree that it's implementable and works with the tokenizer.
My main objection is the verbosity, which is the reason I assume many other
languages have fairly short/distinct attribute syntax.
```
// Assume Unused tells IDEs/analyzers/linters not to warn about unused
parameters,
// and Override warns about a method not being an override
using attribute(Override)
public function apiMethod(
using attribute(Unused)
array $params,
using attribute(Unused)
bool $featureEnabled,
using attribute(Unused)
array $options,
) {...}
```
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi Benjamin,
> The reason is not only Joe's desire to revote on #[], but also that there
> are now more syntax proposals such as @[] by Derick or @@ in comments by
> Tyson (though no patch exists for it yet). At this point a lot of syntaxes
> are potentially viable (except single @, please don't suggest it).
I'd agree, I mentioned earlier that I'd preferred ranked choice over a 2-choice
vote.
Unrelatedly, https://wiki.php.net/rfc/shorter_attribute_syntax_change does not
mention the drawbacks I've mentioned about significantly changing lexing in
unexpected ways (`#Attr('?>')` will start inline HTML in php 7).
People reading the RFC might expect that `#[` would only lead to missing
tokens, not significantly different tokens.
- https://externals.io/message/111218#111239
P.S. I don't plan to create a patch for attributes in comments due
to the long-term drawbacks for those writing tooling/editors for it,
difficulty to learn it, increased complexity of the implementation, etc.
I'd strongly prefer `<<` and `@@` over comments-based syntax.
That was more of "if language designers really, really wanted to write
attributes syntax that would be usable immediately and work with existing
tools, ignoring various drawbacks elsewhere, then what could they implement?"
I don't have objections to anyone attempting to implement it, but I'm not going
to push for it/work on it.
Cheers,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
I would like to suggests the syntax "using attribute(Attribute, ...)". It is more clear and should not create BC. Em qui, 30 de jul de 2020 10:28, Joe Ferguson escreveu: > On Thu, Jul 30, 2020 at 7:50 AM Benjamin Eberlei > wrote: > > > I think it has become clear that we need to revisit this syntax question > > again, including the elephpant in the room of delaying this feature to > 8.1. > > > > The reason is not only Joe's desire to revote on #[], > > > > > No, I *do not* want to revote. This RFC simply takes a formal approach to > approve the syntax that came in 2nd based on concerns raised with the @@ > syntax. > > Now that it seems the technical concerns around @@ have been resolved by > another pending, passing, RFC, I'm still here wanting us to talk about the > impact of @@ on static analysis tools. Apparently, internals doesn't care > about these projects. I care and I'm trying to help. I'm not trying to > revote until I get the vote I want. I'm just a dude that had some free time > while on vacation when he saw a chance to contribute. > > I see two possible outcomes: > > Release Managers collectively should decide what we do to move forward. > Either accept @@, we'll decline this RFC and we can move on to the next > nearest bikeshed. > > OR > > If Release Managers don't want to, or can't collectively make a decision > then this RFC should go to a vote and we'll see what 2/3s of the group > want. > > I'm fine with either outcome. > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > -- > - Joe Ferguson > JoeFerguson.me > osmihelp.org >
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Thu, Jul 30, 2020 at 7:50 AM Benjamin Eberlei wrote: > I think it has become clear that we need to revisit this syntax question > again, including the elephpant in the room of delaying this feature to 8.1. > > The reason is not only Joe's desire to revote on #[], > > No, I *do not* want to revote. This RFC simply takes a formal approach to approve the syntax that came in 2nd based on concerns raised with the @@ syntax. Now that it seems the technical concerns around @@ have been resolved by another pending, passing, RFC, I'm still here wanting us to talk about the impact of @@ on static analysis tools. Apparently, internals doesn't care about these projects. I care and I'm trying to help. I'm not trying to revote until I get the vote I want. I'm just a dude that had some free time while on vacation when he saw a chance to contribute. I see two possible outcomes: Release Managers collectively should decide what we do to move forward. Either accept @@, we'll decline this RFC and we can move on to the next nearest bikeshed. OR If Release Managers don't want to, or can't collectively make a decision then this RFC should go to a vote and we'll see what 2/3s of the group want. I'm fine with either outcome. https://wiki.php.net/rfc/shorter_attribute_syntax_change -- - Joe Ferguson JoeFerguson.me osmihelp.org
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
I think it has become clear that we need to revisit this syntax question again, including the elephpant in the room of delaying this feature to 8.1. The reason is not only Joe's desire to revote on #[], but also that there are now more syntax proposals such as @[] by Derick or @@ in comments by Tyson (though no patch exists for it yet). At this point a lot of syntaxes are potentially viable (except single @, please don't suggest it). I feel the choice between many syntaxes is 80% subjective, 20% objective facts, so tensions are to be expected. As the author of the original RFC and patch, I hope I have some klout in suggesting the following procedure (RMs would need to extend their approval for revote to this). 1. we collect syntax proposals once again, with the requirement of a simple patch being available against php-src/master for viability in 8.0. 2. RMs are the arbiter to decide the patch is acceptable to be included for 8.0 or if its selection would delay entire attributes to 8.1. 3. I would make a feature matrix for the vote / RFC page and sort each proposed syntax into it, seeking input from the proposers. 4. We would then hold another vote on syntax using STV where the choice is a combination of syntax and target version, examples: - <<>> in 8.0, #[] in 8.0, @@ in 8.0 (all these patches are viable) - @@ in doc blocks for 8.1 - §[] in 8.1 (weird example to demonstrate the point) and so on. The STV vote would run with potentially 5-10 different syntaxes. On Time Frame: Sara allowed to extend this decision into feature freeze, but I believe it shouldn't be later than Beta 2 (August 20th), especially if the outcome could be delay until 8.1. What do RMs think of voting from 10th to 17th of August, giving us 3 days to merge. This gives everyone until August 8-9th to work on their syntax proposal. greetings Benjamin On Tue, Jul 28, 2020 at 4:47 PM Joe Ferguson wrote: > Hello Internals, > > I've been working with Derick Rethans and others (thanks all!) on a Shorter > Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax > would be preferred over the currently agreed upon "@@" syntax for Shorter > Attribute Syntax. > > An important part of the research that went into this proposal demonstrates > how "@@" will make handling attributes more difficult for PHP_CodeSniffer > (and similar tools) and shows how the alternative "#[]" syntax is more > friendly for these tools. > > You can find the RFC > https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to > answer any questions as best I can. > > -- > - Joe Ferguson > JoeFerguson.me > osmihelp.org >
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi Theodore, śr., 29 lip 2020 o 21:08 Theodore Brown napisał(a): > ... > Anyway, apart from the fact that feature freeze is less than a week > away, it seems like voting again to use #[] instead of @@ would > violate the voting rules. [1] It hasn't been six months since the > last vote, and this proposal is identical to the one declined in the > previous RFC. > Which declined/rejected RFC you're referring to? I can't find it on the list[1] but would for sure like to read it again. [1] https://wiki.php.net/rfc#declined Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Tue, July 28, 2020 at 6:09 PM Mark Randall wrote: > On 28/07/2020 22:55, Theodore Brown wrote: > > I appreciate the examples. I think there are good reasons not to > > implement these kind of extensions, at least in this form. I'll reply > > to each example below. > > > The problem is your argument comes from a position of... because you > don't like those examples, we shouldn't make accomodation for them or > anything like them in future. > > Adopting such extensions is a matter for a future RFC, and not for > preemptively throwing a spanner in the works. Hi Mark, Future RFCs are as free as they've always been to propose new additions and extensions. Do you think we need to choose a more verbose syntax for every new feature in PHP just to make sure it accommodates keyword flags on the off-chance we may want to add them later? E.g. should we re-vote on the named arguments RFC now and replace the syntax with something designed around adding flags to each argument (e.g. so that function calls could support both an old and new parameter names and be compatible with multiple library versions)? There's good reason to believe that such added complexity is not the best approach, and is very unlikely to be accepted. Preemptively implementing a more verbose syntax with a larger BC break, on the basis of hypothetical extensions which haven't been needed in any other language isn't a good approach to language design, in my view. Anyway, apart from the fact that feature freeze is less than a week away, it seems like voting again to use #[] instead of @@ would violate the voting rules. [1] It hasn't been six months since the last vote, and this proposal is identical to the one declined in the previous RFC. Best regards, Theodore [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi Joe, wt., 28 lip 2020 o 16:47 Joe Ferguson napisał(a): > Hello Internals, > > I've been working with Derick Rethans and others (thanks all!) on a Shorter > Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax > would be preferred over the currently agreed upon "@@" syntax for Shorter > Attribute Syntax. > > An important part of the research that went into this proposal demonstrates > how "@@" will make handling attributes more difficult for PHP_CodeSniffer > (and similar tools) and shows how the alternative "#[]" syntax is more > friendly for these tools. > > You can find the RFC > https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to > answer any questions as best I can. > Thank you for bringing this up. TIL something new about popular framework templating component which I wanna share with you. There is already use of @@ in files with ".php" extension in Blade templates from Laravel framework. In Laravel 7.x double @@ is used as an escape sequence allowing template compiler to passthrough TypeScript expressions with @decorator() which is described in the Templating section of manual[1]. I realize that it's not the same cause the double @@ is used here inside ".php" files in HTML mode and not in PHP code mode but since this feature exist it may cause issues on a text search lookup using for eg. grep | sed | awk like tools. TL;DR Now please bear in mind that I'm just saying that people from Larevil community already can use the same syntax with double "@@name()" in ".php" files but outside of PHP code context. [1] https://laravel.com/docs/7.x/blade#blade-and-javascript-frameworks Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi internals,
I had thought of another alternative syntax - `/** @@MyAttribute */`, which
would solve some of the problems I mentioned about `#[`.
```
namespace My\NS;
use Other\MyAttribute;
/**
* Use @@ or << at the start of a line. (To be determined)
* Resolve the names in the comment relative to the scope of the function, like
the current attribute implementation.
* @@MyAttribute(expr, expr)
* Extra *s are allowed
*** @@AnotherAttribute
* Tokenizing should continue until a matching ) is found
* @@YetAnotherAttribute(
* expr
*)
*/
function my_function() {
}
```
Pros:
- Doc comments are already the recommended way to associate information with a
named element.
- Most code modifying tools will preserve doc comments
- This can go on the same line as a closure/short arrow function without lexing
ambiguity.
- Frameworks can use `Reflection*->getDocComment()` and update their checks to
also allow `@@` for attribute-like annotations when run in PHP 7.
They don't have to repeat both `@@MyAttribute` and `/** @MyAttribute */` or
risk it going out of sync
(Symfony would already have to parse the `use` clauses to find out what
`@MyAttribute` resolves to for Symfony attributes)
- Does not affect lexing outside of the doc comment
- I don't believe @@ is common. To minimize the impact on ascii art, this can
be initially limited to @@ at the start of a comment line (spaces and `*`s)
immediately followed by \ or the start of an identifier
Cons:
- Need to run the lexer twice on a T_DOC_COMMENT token, but only if the comment
string contains `@@` and is associated with an element.
Emitting T_DOC_COMMENT_START and T_DOC_COMMENT_END and T_DOC_COMMENT_INNER
and T_DOC_COMMENT_ATTRIBUTE
T_DOC_COMMENT_ATTRIBUTE_ERROR might make this technically feasible (similar
to heredoc having complicated logic)
- I prefer `@@` and `<<>>` over this proposal long-term, after php 7.4 support
is dropped.
But I prefer `/** @@MyAttr */` over `#[MyAttr]`.
- Would end up emitting parse errors for some existing code in the second lexer
pass.
- Syntax highlighting might be hard to implement in editors, but probably
tractable.
I don't remember seeing this proposed before. I believe @@ isn't used by
mainstream frameworks in doc comments right now, but correct me if it is.
Thanks,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi Michal, > On Jul 29, 2020, at 01:13, Michał Marcin Brzuchalski > wrote: > > Hi Paul, > > wt., 28 lip 2020 o 20:56 Paul M. Jones napisał(a): > >> ... >> Let's count. + is "change away from @@ to anything else", - is "stay with >> @@", ? is hard-to-tell/weak/uncertain/they-all-suck. >> ... >> Michal Brzuchalski: -? >> > > Wow. Hold on your horses. I was never in favour for @@ but always against > at least AFAIR. > Where did you get that? > > Anyway it should be ++ here Ah yes, clearly a mistake -- my apologies. > It's hard to rely fully on your statement considering such a mistake. I encourage you (and everyone sle who is interested!) to go back and check that Twitter thread to see if I have made other errors. In the absence of them, my conclusion still stands: that is, "the majority of Twitter respondents in that thread appear to be against @@, and in favor of 'something else'." -- 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] [Discussion] Shorter Attribute Syntax Change
Hello Internals, Here is a small comparison table based on current feedback, maybe it will bring some objective clarity to the discussion: (markdown below) Impact|`@@`|`#[]` ---|---|--- BC break|virtualy nonexistent|slightly broader: `##[` comments are now broken. Parser|no technical problems by now|no technical problems by now Extendability|less future-proof, arguably|more future-proof, arguably Grepability|harder, arguably|easier, arguably (however, consider an Attribute taking an array `[]` parameter.) Perception|similar to PHPDoc annotations, more familiar to PHP devs|more familiar to Rust devs Other issues are either speculative or insignificant (as for me): - causing future parsing issues: no evidence - "backfilling": there is, arguably, no use case for it. Code using PHP 8 features will target PHP 8 anyway. Code, compatible with both PHP 7 and PHP 8 would most probably use classic PHPDoc annotations. - "syntax no other language uses": this is probably insignificant. - "possibility of @@ moving to @ is near to 0": i am not sure anyone planned to move @@ to @, and if so, it would be an unnecessary BC break. I am personally in favor of `@@`, but just because it looks visually nicer to me. I see no strong objective reason to favor one over the other. If you want an ending token, maybe consider `@@Attribute@@`, personally I like those round-ish shapes :P. On Tue, Jul 28, 2020 at 5:47 PM Joe Ferguson wrote: > > Hello Internals, > > I've been working with Derick Rethans and others (thanks all!) on a Shorter > Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax > would be preferred over the currently agreed upon "@@" syntax for Shorter > Attribute Syntax. > > An important part of the research that went into this proposal demonstrates > how "@@" will make handling attributes more difficult for PHP_CodeSniffer > (and similar tools) and shows how the alternative "#[]" syntax is more > friendly for these tools. > > You can find the RFC > https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to > answer any questions as best I can. > > -- > - Joe Ferguson > JoeFerguson.me > osmihelp.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Wed, Jul 29, 2020 at 2:21 AM tyson andre
wrote:
> Hi internals,
>
> For #[, my main objection is the various ways this can change the lexing
> in a way that is impractical to (efficiently) backfill,
> and that the proposed patch doesn't address the fact that the syntax may
> change the syntax of php 7 code in unexpected ways.
>
> This syntax would help phpcs with easy examples **in the short term**,
> when attributes are on a single line,
> but would make more complicated refactorings buggy and error-prone unless
> phpcbf was run in the same major version.
> When attributes span multiple lines, the lexing is completely different
> for `#[]`.
> For example, the below syntax would yield false in php 7, but a generator
> in php 8.
> (There's precedent at least - the lexing of heredocs changed in php 7.3 or
> 7.4)
>
That's an interesting point. Emulating #[] lexing on older versions will
definitely be a challenge for PHP-Parser. I don't think we should make
concerns of external tooling hold us back too much, but the phpcs argument
really doesn't hold water.
Regards,
Nikita
> ```
> // Aside: This code snippet seems to have an assert failure in the lexer
> with the patch in the RFC
> // Zend/zend_compile.c:1794: zendlex: Assertion
> `!(executor_globals.exception) || ret == T_ERROR' failed.
> function generator() {
> yield #[MyCustomAttribute('
> false;
> // ']function() {};
> }
> ```
>
> And another example which would cause problems for phpcs in php 7 - the
> comment syntax can cause code to be treated as inline html instead of php
> tokens.
>
> ```
> // This example echoes the rest of the source code in php 7
> // and echoes "Test" in php 8.
> #[DeprecationReason('reason: ')]
> function main() {}
> const APP_SECRET = 'app-secret';
> echo "Test\n";
> ```
>
> I'd posted another example in https://externals.io/message/01#33
>
> One way I'd thought of to avoid this ambiguity would be to assert in PHP
> 8.0 with an E_COMPILE_ERROR (or E_COMPILE_WARNING) that:
> 1. All tokens of the #[...] annotation are on the same line
> 2. No non-whitespace token follows the ] on the same line.
> It may be permissible to allow other `//` comments or multiple
> attributes after it on the same line, though.
> 3. No `?>` substrings within the rest of the line after #[, maybe
>
> Although I'm not sure if others are actually concerned about this
> ambiguity and these are really artificial examples for code.
>
> As for `<<`, I'm assuming people may have meant `yield <> function()
> {};`,
> but `yield` already has a precedence and didn't have issues - otherwise
> `yield+2;` could be adding 2 to the result of a yield.
> (It's unambiguously `yield(+2);` right now).
> I forget how it'd be parsed, but it wouldn't be ambiguous.
>
> As for `@@`, all of its known issues seem to have been resolved,
> and there is still the potential for future issues, but I still prefer it
> over the `#[` implementation in that patch.
>
> P.S. I'd like to note that
> 1. A lot more discussion has occurred since the initial vote.
> 2. Since `@@` was obviously passing at the time, fewer voters would put
> much thought into detailed tradeoffs of `#[`
> 3. I haven't seen those specific drawbacks to `#[` of potentially
> significantly changing lexing (not just losing tokens) mentioned,
>but the shorter attributes syntax RFC did seem to mention params were
> commented out.
>
> One idea I'd have on voting would be to have the exact same 3-way vote,
> again, and pick the attribute syntax with the same ranked choice procedure.
> I assume proponents of `#[` would have similar objections if an RFC with a
> two-way vote for `<<>>` and `@@` was started first.
>
> Regards,
> - Tyson
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi Paul, wt., 28 lip 2020 o 20:56 Paul M. Jones napisał(a): > ... > Let's count. + is "change away from @@ to anything else", - is "stay with > @@", ? is hard-to-tell/weak/uncertain/they-all-suck. > ... > Michal Brzuchalski: -? > Wow. Hold on your horses. I was never in favour for @@ but always against at least AFAIR. Where did you get that? Anyway it should be ++ here > > ++: 13 definitely prefer changing to something other than @@ (though not > necessarily #[]) > ++: 14 definitely prefer changing to something other than @@ (though not necessarily #[]) > +?: 10 probably prefer changing to something other than @@ (though not > necessarily #[]) > ??: 23 hard-to-tell/weak/uncertain/they-all-suck > -?: 3 probably prefer to keep @@ > -?: 2 probably prefer to keep @@ --: 4 definitely prefer to keep @@ > It's hard to rely fully on your statement considering such a mistake. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi Joe,
Personally I favor #[] myself, but there has been a vote with a substantial
participation choosing @@. Overturning this democratic outcome should
require **significant** technical arguments, otherwise this RFC would
provide problematic precedent for any RFC to be overturned by arbitrary
revoting.
The arguments the RFC brings forward don't convince me that we should pick
#[] over @@.
1. The parser conflict was my major reason why @@ should not have been
picked from a technical POV. But this issue has been fixed by an
independent improvement since then. These kinds of small problems are found
regularly after RFCs are accepted and are subsequently fixed. The RFC is
formulated as the problem still exists, but it does not. Yes, the namespace
token RFC vote has not yet finished, but there is no chance it will be
rejected at this point.
Since the namespace token RFC is passing, and I have seen the simplicity of
the new parser rules, my opinion has changed to keep pushing for #[] and I
accept the @@ outcome.
2. The phpcs argument also does not convince me.
Summed up it is essentially that a current version of phpcs does not
support parsing @@ or <<>> yet and incorrectly changes code using them,
however for #[] it does nothing because it parses it as a comment. To me
this sounds like a bug in PHPCS. This argument also breaks down completely
on multi line attributes.
Why should we even expect PHPCS to support an unreleased version? If
someone uses PHP 8 code, why do we assume they keep using an old version of
phpcs that does not support PHP 8 yet?
3. We already established that the syntax question is extremely
contentious, and I was getting tons of messages on it on Twitter, Reddit,
Email et al during the initial Attributes RFC. So of course people would be
against @@ (as I am myself), however it had a majority in votes.
For me putting these subjective opinions into the RFC makes the case for
overturning less convincing, because it makes the argument that overturning
a valid democratic vote is somehow OK if you are loud.
The only reason why we change this outcome must be purely technical imho.
4. You cannot write a regex to detect the end symbols for both #[] or <<>>,
because both end symbols are allowed *inside* the attribute syntax already,
so it's not easier to find occurrences with regexes with the other syntaxes:
#[Foo([1 => 2])]
<> 4)>>
Simple detection of attributes will always need to grep only for the start
token, and both @@ and #[ are equally unique to find here.
5. For readability an end token would be nicer (which is why i prefer #[]).
But this information was already known during the first vote on the syntax
and rejected by majority.
6. An end token might indeed allow extending attributes with new stuff, but
nobody has brought up this use-case before. No other language has
additional attribute keywords, why is this brought as a positive argument,
when the choice of syntax no other language uses is brought up as a
negative point later?
7. Future potential parsing problems are brought forward for @@, but #
being a comment token makes it likely that #[] will also cause problems.
Tyson has a few examples in his email to this thread.
Other confusing things you can do with #[] for example:
#[Foo( 1 # 1 ] bar
)]
function foo () { }
Which is #[Foo(1)] without comments and line breaks.
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi internals,
For #[, my main objection is the various ways this can change the lexing in a
way that is impractical to (efficiently) backfill,
and that the proposed patch doesn't address the fact that the syntax may change
the syntax of php 7 code in unexpected ways.
This syntax would help phpcs with easy examples **in the short term**, when
attributes are on a single line,
but would make more complicated refactorings buggy and error-prone unless
phpcbf was run in the same major version.
When attributes span multiple lines, the lexing is completely different for
`#[]`.
For example, the below syntax would yield false in php 7, but a generator in
php 8.
(There's precedent at least - the lexing of heredocs changed in php 7.3 or 7.4)
```
// Aside: This code snippet seems to have an assert failure in the lexer with
the patch in the RFC
// Zend/zend_compile.c:1794: zendlex: Assertion `!(executor_globals.exception)
|| ret == T_ERROR' failed.
function generator() {
yield #[MyCustomAttribute('
false;
// ']function() {};
}
```
And another example which would cause problems for phpcs in php 7 - the comment
syntax can cause code to be treated as inline html instead of php tokens.
```
https://some-website/reason?>')]
function main() {}
const APP_SECRET = 'app-secret';
echo "Test\n";
```
I'd posted another example in https://externals.io/message/01#33
One way I'd thought of to avoid this ambiguity would be to assert in PHP 8.0
with an E_COMPILE_ERROR (or E_COMPILE_WARNING) that:
1. All tokens of the #[...] annotation are on the same line
2. No non-whitespace token follows the ] on the same line.
It may be permissible to allow other `//` comments or multiple attributes
after it on the same line, though.
3. No `?>` substrings within the rest of the line after #[, maybe
Although I'm not sure if others are actually concerned about this ambiguity and
these are really artificial examples for code.
As for `<<`, I'm assuming people may have meant `yield <> function() {};`,
but `yield` already has a precedence and didn't have issues - otherwise
`yield+2;` could be adding 2 to the result of a yield.
(It's unambiguously `yield(+2);` right now).
I forget how it'd be parsed, but it wouldn't be ambiguous.
As for `@@`, all of its known issues seem to have been resolved,
and there is still the potential for future issues, but I still prefer it over
the `#[` implementation in that patch.
P.S. I'd like to note that
1. A lot more discussion has occurred since the initial vote.
2. Since `@@` was obviously passing at the time, fewer voters would put much
thought into detailed tradeoffs of `#[`
3. I haven't seen those specific drawbacks to `#[` of potentially significantly
changing lexing (not just losing tokens) mentioned,
but the shorter attributes syntax RFC did seem to mention params were
commented out.
One idea I'd have on voting would be to have the exact same 3-way vote, again,
and pick the attribute syntax with the same ranked choice procedure.
I assume proponents of `#[` would have similar objections if an RFC with a
two-way vote for `<<>>` and `@@` was started first.
Regards,
- Tyson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On 28/07/2020 22:55, Theodore Brown wrote: I appreciate the examples. I think there are good reasons not to implement these kind of extensions, at least in this form. I'll reply to each example below. The problem is your argument comes from a position of... because you don't like those examples, we shouldn't make accomodation for them or anything like them in future. Adopting such extensions is a matter for a future RFC, and not for preemptively throwing a spanner in the works. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Tue, July 28, 2020 at 2:38 PM Mark Randall wrote: > On 28/07/2020 18:57, Theodore Brown wrote: > >> Having a closing ] makes it easier to extend Attributes with more syntax > > > > This might be a good argument if there were actually a need to extend > > attributes with more syntax. What other languages have found a need for > > this? Even Rust doesn't allow additional syntax inside the brackets. > > Just because they haven't, does not mean we won't. Unless there's a good > reason to do otherwise, we should provide for future flexibility where > possible. > > I previously provided examples of ways in which we might want to extend > the syntax. Hi Mark, I appreciate the examples. I think there are good reasons not to implement these kind of extensions, at least in this form. I'll reply to each example below. > Most things in PHP allow some level of scope restriction, such as > private or protected. One day we may want to extend annotations to > include such a feature, such as a protected annotation that can only be > accessed by the class itself or its descendants. > > #[protected MyAttribute(xyz)] Given that attributes are metadata, restricting their scope seems rather pointless, and probably would only encourage their (mis)use for things they aren't the right solution for. Isn't the whole point of an attribute to be read by something outside the class? If the metadata is only for the class itself, class constants with appropriate visibility can be used instead. > Attributes are not validated when they are encountered, this may be > something that we wish to allow attributes to opt-in to in future. > > #[checked MyAttribute(xyz]) I hope if we allow opting into such a feature it won't have to be so verbose and won't require making checked a new reserved keyword. I suppose the same thing could be accomplished with a distinct token, for example: @@!MyAttribute(xyz) > In future we might want to offer APIs that return an array of all of the > instances (moving the creation up from newInstance) and then tighten up > the behvaiour for classes which do not exist (because they might belong > to an optional package, such as debugging or code analysis). This might > come in the form of something like: > > #[optional MyAttribute(xyz)] Existing attributes are already optional, though, so it's not clear what value this would add. If we want some attributes to not be optional, we could add a new syntax for checked attributes like the previous example. > Some of these might happen, none of these might happen, something > completely different might happen. > > What is clear is we've got to support Attributes for 20, 30 years, and > we should leave the door open for easier and cleaner syntax additions if > there's no compelling reason not to. I'm not convinced this approach of additional keywords before an attribute is the easiest or cleanest way to implement additions. It seems like it could lead to more BC breaks and unnecessary verbosity if it encourages adding new keywords. And as you point out, whether any such additions happen is completely hypothetical right now. In the present what we do know is that #[] is a bigger BC break than @@, and that other languages haven't had a need for such syntax additions in the many years that attributes have been around. Best regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
(Top posting because... sue me.) I hereby propose to use @[] syntax for attributes. No need to vote; it's clearly the best, nay only, real option. Make it so. P.S. Sorry for suggesting @@ earlier, I've no idea what I was thinking. Creating new syntax is HARD! P.P.S. <3 On Tue, 28 Jul 2020 at 20:59, Marcio Almada wrote: > Hi, > > > > > On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown > > wrote: > > > > > > > > Hi Joe, > > > > > > From the perspective of looks alone I don't care much one way or the > > > other between @@ and #[]. However, I don't find the arguments for #[] > > > in this RFC very compelling, and it ignores some of the other downsides > > > of #[] compared to @@ that should be highlighted. Let's go through the > > > arguments from the RFC: > > > > > > > > > > > Theodore, thanks for your comments, time, and work on the Shorter > Attribute > > Syntax RFC. I appreciate your feedback and I'm also of the mind where I > > don't care based on looks alone. The RFC also notes the @@ issues have > been > > resolved by the RFC closing at the end of the month. > > > > My motivation for this RFC is based on 2 things: > > > > Firstly, the @@ syntax makes parsing harder (although not impossible) on > > CLI tools such as PHPCS. Therefore IMHO internals should make the best > > effort to avoid this when possible. > > > > Secondly, I'd like to see internals use this as a point in the future to > > avoid this kind of issue where we need to vote on something yet again > > instead of taking the runner up in a ranked-choice vote. Originally this > > was my main motivation until I saw the issues raised by the PHPCS users. > > > > Is this issue documented somewhere on github or on any other platform? > I'd like to see the discussion and maybe participate in it. > > Thanks, > Márcio > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi, > > On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown > wrote: > > > > > Hi Joe, > > > > From the perspective of looks alone I don't care much one way or the > > other between @@ and #[]. However, I don't find the arguments for #[] > > in this RFC very compelling, and it ignores some of the other downsides > > of #[] compared to @@ that should be highlighted. Let's go through the > > arguments from the RFC: > > > > > > Theodore, thanks for your comments, time, and work on the Shorter Attribute > Syntax RFC. I appreciate your feedback and I'm also of the mind where I > don't care based on looks alone. The RFC also notes the @@ issues have been > resolved by the RFC closing at the end of the month. > > My motivation for this RFC is based on 2 things: > > Firstly, the @@ syntax makes parsing harder (although not impossible) on > CLI tools such as PHPCS. Therefore IMHO internals should make the best > effort to avoid this when possible. > > Secondly, I'd like to see internals use this as a point in the future to > avoid this kind of issue where we need to vote on something yet again > instead of taking the runner up in a ranked-choice vote. Originally this > was my main motivation until I saw the issues raised by the PHPCS users. > Is this issue documented somewhere on github or on any other platform? I'd like to see the discussion and maybe participate in it. Thanks, Márcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Tue, Jul 28, 2020 at 12:57 PM Theodore Brown wrote: > > Hi Joe, > > From the perspective of looks alone I don't care much one way or the > other between @@ and #[]. However, I don't find the arguments for #[] > in this RFC very compelling, and it ignores some of the other downsides > of #[] compared to @@ that should be highlighted. Let's go through the > arguments from the RFC: > Theodore, thanks for your comments, time, and work on the Shorter Attribute Syntax RFC. I appreciate your feedback and I'm also of the mind where I don't care based on looks alone. The RFC also notes the @@ issues have been resolved by the RFC closing at the end of the month. My motivation for this RFC is based on 2 things: Firstly, the @@ syntax makes parsing harder (although not impossible) on CLI tools such as PHPCS. Therefore IMHO internals should make the best effort to avoid this when possible. Secondly, I'd like to see internals use this as a point in the future to avoid this kind of issue where we need to vote on something yet again instead of taking the runner up in a ranked-choice vote. Originally this was my main motivation until I saw the issues raised by the PHPCS users. I don't want this to become an issue of "keep voting until we get the vote we like" as Paul mentioned. This RFC is my attempt to set a precedent where internals allows itself to be some measurement more autonomous than it currently is today. And also to try to make the 8.0 upgrade process a bit friendlier to our fiends writing userland code. https://wiki.php.net/rfc/shorter_attribute_syntax -- - Joe Ferguson JoeFerguson.me osmihelp.org
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
> On Jul 28, 2020, at 14:15, Ben Ramsey wrote: > >> On Jul 28, 2020, at 14:10, Paul M. Jones wrote: >> >>> On Jul 28, 2020, at 14:07, Ben Ramsey wrote: >>> On Jul 28, 2020, at 13:55, Paul M. Jones wrote: Now, it may be that #[] or <<>> or something else actually is "better" in some sense that cannot be articulated. But if there are no existing technical hurdles to be overcome with the already-voted-on-and-accepted solution of @@, what technically compelling reason can there be to revote? >>> >>> >>> IMO, there is no compelling reason to revote other than the fact that we >>> have no process for what to do in this situation. >> >> What "situation" is this, exactly? AFICT we have a working implementation >> using @@, with no technical hurdles to surmount. Or have I missed something >> that now prevents @@ from working per its RFC? > > > The new RFC outlines reasons why `@@` is a sub-optimal choice. And yet it was the one chosen by the voting process. (Silly voters, making sub-optimal choices!) The rest of your message reveals what I thought was true: i.e., there are no currently-verified technical barriers to @@. To wit: > * current parser conflict (which can be worked around) AFAICT that pre-existing problem has been fixed, so this is a non-issue. > * possibility for further (as of yet unknown) parsing issues IOW, imaginary issues, aka FUD. > * a closing ] makes it easier to extend Attributes with more syntax, and at > the same time not be at the risk of running into parser conflicts Maybe, maybe not. This has the strongest possibility of becoming a technical argument, but no competing implementation (with a comparative implementation using @@) has been presented as an example. So as it stands now, this also is imaginary. > * userland analysis tools have difficulties parsing `@@` Though it does not seem insurmountable for those userland authors. Also, this is an interesting take: does Internals now defer to userland? If so, maybe it's time to open up voting more widely, so that the whole of userland can be represented more effectively here. Again, I don't especially care if @@, <<>>, or #[], or something else makes it through. Annotations of some sort seem like a nice idea, and I think they'd be of benefit. But if we are to make decisions by what is ostensibly a democratic process, we should stick to the voted decisions, instead of re-voting issues until the voters "get it right" according to some implicit and unstated criteria. (If re-voting over and over is the plan, I've got some RFCs I might like to revisit as well.) -- 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] [Discussion] Shorter Attribute Syntax Change
On 28/07/2020 18:57, Theodore Brown wrote: Having a closing ] makes it easier to extend Attributes with more syntax This might be a good argument if there were actually a need to extend attributes with more syntax. What other languages have found a need for this? Even Rust doesn't allow additional syntax inside the brackets. Just because they haven't, does not mean we won't. Unless there's a good reason to do otherwise, we should provide for future flexibility where possible. I previously provided examples of ways in which we might want to extend the syntax. Most things in PHP allow some level of scope restriction, such as private or protected. One day we may want to extend annotations to include such a feature, such as a protected annotation that can only be accessed by the class itself or its descendants. #[protected MyAttribute(xyz)] Attributes are not validated when they are encountered, this may be something that we wish to allow attributes to opt-in to in future. #[checked MyAttribute(xyz]) In future we might want to offer APIs that return an array of all of the instances (moving the creation up from newInstance) and then tighten up the behvaiour for classes which do not exist (because they might belong to an optional package, such as debugging or code analysis). This might come in the form of something like: #[optional MyAttribute(xyz)] Some of these might happen, none of these might happen, something completely different might happen. What is clear is we've got to support Attributes for 20, 30 years, and we should leave the door open for easier and cleaner syntax additions if there's no compelling reason not to. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
> On Jul 28, 2020, at 14:10, Paul M. Jones wrote: > >> On Jul 28, 2020, at 14:07, Ben Ramsey wrote: >> >>> On Jul 28, 2020, at 13:55, Paul M. Jones wrote: >>> >>> Now, it may be that #[] or <<>> or something else actually is "better" in >>> some sense that cannot be articulated. But if there are no existing >>> technical hurdles to be overcome with the already-voted-on-and-accepted >>> solution of @@, what technically compelling reason can there be to revote? >> >> >> IMO, there is no compelling reason to revote other than the fact that we >> have no process for what to do in this situation. > > What "situation" is this, exactly? AFICT we have a working implementation > using @@, with no technical hurdles to surmount. Or have I missed something > that now prevents @@ from working per its RFC? The new RFC outlines reasons why `@@` is a sub-optimal choice. TL;DR: * current parser conflict (which can be worked around) * possibility for further (as of yet unknown) parsing issues * a closing ] makes it easier to extend Attributes with more syntax, and at the same time not be at the risk of running into parser conflicts * userland analysis tools have difficulties parsing `@@` Cheers, Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
> On Jul 28, 2020, at 14:07, Ben Ramsey wrote: > >> On Jul 28, 2020, at 13:55, Paul M. Jones wrote: >> >> Now, it may be that #[] or <<>> or something else actually is "better" in >> some sense that cannot be articulated. But if there are no existing >> technical hurdles to be overcome with the already-voted-on-and-accepted >> solution of @@, what technically compelling reason can there be to revote? > > > IMO, there is no compelling reason to revote other than the fact that we have > no process for what to do in this situation. What "situation" is this, exactly? AFICT we have a working implementation using @@, with no technical hurdles to surmount. Or have I missed something that now prevents @@ from working per its RFC? -- 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] [Discussion] Shorter Attribute Syntax Change
> On Jul 28, 2020, at 13:55, Paul M. Jones wrote: > > Now, it may be that #[] or <<>> or something else actually is "better" in > some sense that cannot be articulated. But if there are no existing technical > hurdles to be overcome with the already-voted-on-and-accepted solution of @@, > what technically compelling reason can there be to revote? IMO, there is no compelling reason to revote other than the fact that we have no process for what to do in this situation. However, given that we used ranked-choice voting in the last RFC, the logical choice (to me) seems to be: choose the runner-up in the event that the winner is disqualified. So, if there are extenuating circumstances that result in `@@` being disqualified, we should automatically default to the runner-up in the ranked-choice outcome. Cheers, Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi all, > On Jul 28, 2020, at 12:57, Theodore Brown wrote: > >> On Tue, July 28, 2020 at 9:46 AM Joe Ferguson wrote: >> >> ... >> >> Feedback to Derick's tweet >> (https://twitter.com/derickr/status/1285912223639130114) >> were [sic] overwhelmingly positive > > Are you sure? I took a look at the thread and it seems like the > responses were pretty mixed. Let's count. + is "change away from @@ to anything else", - is "stay with @@", ? is hard-to-tell/weak/uncertain/they-all-suck. Derick Rethans: ++ Rafael Dohms: +? Alexander Berl: -? Chris Emerson: -- Tamas Erdelyi: ?? Phili Weinke: ?? Trent: ++ Juriaan Ruitenberg: ++ Mehran: ++ Stephan Hochdorfer: ?? Cees-Jan Kiewiet: ?? Tom Witkowski: ++ Matiss: ++ Henry Paradiz: -- Saif: ?? Paul Redmond: ?? Marco Pivetta: ++ Simon Champion: ?? @eimihar: ?? Brent: +? Graham Campbell: +? Dmitri Goosens: ++ Sergej Kurakin: -? Francis Lavoie: ?? Michael Moravec: ?? John Hunt: ?? Lars Moelleken: ?? Michal Brzuchalski: -? Kyrre: ?? Steve MacDougall: ++ Agustin Gomes: ?? Mike Rockett: ++ Matias Navarro: ++ Marisa Clardy: ++ Warp Speed: -- WJB: +? Martijn Minnis: -- Dennis de Best: ?? Damo: ?? SOFTonSOFA: +? Ashish K. Poudel: +? Bastien Remy: ?? Matiss: +? Thierry D.: +? Ihor Vorotnov: ?? Hugo Alliaume: ?? Juan Millan: +? Olbaum: +? Steve Baumann: ?? James Mallison: ?? Marco Deleu: ?? TheGenuinenessSheriff: ++ Golgote: ?? ++: 13 definitely prefer changing to something other than @@ (though not necessarily #[]) +?: 10 probably prefer changing to something other than @@ (though not necessarily #[]) ??: 23 hard-to-tell/weak/uncertain/they-all-suck -?: 3 probably prefer to keep @@ --: 4 definitely prefer to keep @@ So, the majority of Twitter respondents in that thread appear to be against @@, and in favor of "something else" (24 to 7). Having pointed all that out, I note that Twitter is not the voting mechanism here. Further, I opine that "voting repeatedly until the voters get it 'right' and then calling the matter settled for all time" is not how decision-by-voting is supposed to work. Now, it may be that #[] or <<>> or something else actually is "better" in some sense that cannot be articulated. But if there are no existing technical hurdles to be overcome with the already-voted-on-and-accepted solution of @@, what technically compelling reason can there be to revote? -- 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] [Discussion] Shorter Attribute Syntax Change
On Tue, July 28, 2020 at 9:46 AM Joe Ferguson wrote: > Hello Internals, > > I've been working with Derick Rethans and others (thanks all!) on a Shorter > Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax > would be preferred over the currently agreed upon "@@" syntax for Shorter > Attribute Syntax. > > An important part of the research that went into this proposal demonstrates > how "@@" will make handling attributes more difficult for PHP_CodeSniffer > (and similar tools) and shows how the alternative "#[]" syntax is more > friendly for these tools. > > You can find the RFC > https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to > answer any questions as best I can. Hi Joe, >From the perspective of looks alone I don't care much one way or the other between @@ and #[]. However, I don't find the arguments for #[] in this RFC very compelling, and it ignores some of the other downsides of #[] compared to @@ that should be highlighted. Let's go through the arguments from the RFC: > It [@@] currently causes a parser conflict This isn't true now that namespaced names are treated as tokens. The @@ implementation has been merged into php-src and there is no parser conflict. > Various luminaires [sic] consider @@ a joke Who does this refer to? A random Reddit user? > Feedback to Derick's tweet > (https://twitter.com/derickr/status/1285912223639130114) > were [sic] overwhelmingly positive Are you sure? I took a look at the thread and it seems like the responses were pretty mixed. Some people expressed support for #[], but almost as many were happier with the @@ syntax. If anything the majority of responses were neutral or expressing dislike for all the syntax options. > It has the distinct possibility to cause further parsing issues Like what? How is it any more likely to cause parsing issues than the @ syntax used by the majority of other C family languages? > Having a closing ] makes it easier to extend Attributes with more syntax This might be a good argument if there were actually a need to extend attributes with more syntax. What other languages have found a need for this? Even Rust doesn't allow additional syntax inside the brackets. > There is no “end symbol” to make finding occurrences easier, > including by reading or using regular expressions. Can you provide an example? When reading code I personally don't find the ending bracket very helpful - my brain tends to parse it as the end of an array, not the end of an attribute. Even when using a regex to search code, the ending bracket doesn't seem very helpful since arrays can also be passed as attribute arguments. For example, to match this attribute the regex for @@ is actually simpler than the one for #[]: ```php # regex: /@@\w+\(.+\)/ @@Attr([1, 2]) # vs. # regex: /#\[\w+\(.+\)\]/ #[Attr([1, 2])] ``` > A syntax with a closing demarcation is much easier to back fill with > tools such as PHPCS. I'm not sure I understand this. What does it mean to "back fill" a syntax with PHPCS, and what does a closing demarcation have to do with it? As a user, I'd expect to have to update PHPCS to work with PHP 8 code - doesn't it have to be updated anyway to correctly support the syntax for named arguments, union types, the nullsafe operator, match expression, etc.? And from a perspective of compatibility with existing tools, couldn't @@ be considered superior since people can use it in code examples on a blog without the syntax highlighter treating it as a comment? > It is a syntax no other language uses. Rust chose to use #[] even though it wasn't used by any other language. Does that make it a bad fit for Rust? No. But just because Rust uses a syntax also doesn't mean it's a good fit for PHP. @@ fits well with PHP since there is virtually no BC break, and the syntax is close to the @annotation syntax currently used in docblocks, so it's easily recognizable for what it is. On the other hand, #[] would be a larger BC break and can easily be confused for a comment. Best regards, Theodore -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Am 28.07.2020 um 17:50 schrieb Derick Rethans: This is an excellent RFC highlighting the important deficiencies of the @@ syntax. I hope you will all read this and also conclude that we can still pick this better syntax. Remember that it is not only about how it looks. It is much more important that it is functional and causes the least amount of friction in the community. Hear, hear. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
On Tue, 28 Jul 2020, Joe Ferguson wrote: > I've been working with Derick Rethans and others (thanks all!) on a > Shorter Attribute Syntax Change RFC which outlines reasons why the > "#[]" syntax would be preferred over the currently agreed upon "@@" > syntax for Shorter Attribute Syntax. This is an excellent RFC highlighting the important deficiencies of the @@ syntax. I hope you will all read this and also conclude that we can still pick this better syntax. Remember that it is not only about how it looks. It is much more important that it is functional and causes the least amount of friction in the community. 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] [Discussion] Shorter Attribute Syntax Change
> On Jul 28, 2020, at 10:13, Côme Chilliet > wrote: > > Le Tue, 28 Jul 2020 09:46:38 -0500, > Joe Ferguson a écrit : > >> Hello Internals, >> >> I've been working with Derick Rethans and others (thanks all!) on a Shorter >> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax >> would be preferred over the currently agreed upon "@@" syntax for Shorter >> Attribute Syntax. >> >> An important part of the research that went into this proposal demonstrates >> how "@@" will make handling attributes more difficult for PHP_CodeSniffer >> (and similar tools) and shows how the alternative "#[]" syntax is more >> friendly for these tools. >> >> You can find the RFC >> https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to >> answer any questions as best I can. >> > > The text uses « instead of <<, it’s confusing. > > It should be made clearer what #[ ] has over << >>, which does not cause any > BC > break. > > Côme I don’t know that it’s valuable to spend time discussing advantages over `<< >>`. Isn’t it clear from the previous RFC[^1] that `@@` and `#[ ]` both won out over `<< >>`? Cheers, Ben [^1]: https://wiki.php.net/rfc/shorter_attribute_syntax signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Le Tue, 28 Jul 2020 09:46:38 -0500, Joe Ferguson a écrit : > Hello Internals, > > I've been working with Derick Rethans and others (thanks all!) on a Shorter > Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax > would be preferred over the currently agreed upon "@@" syntax for Shorter > Attribute Syntax. > > An important part of the research that went into this proposal demonstrates > how "@@" will make handling attributes more difficult for PHP_CodeSniffer > (and similar tools) and shows how the alternative "#[]" syntax is more > friendly for these tools. > > You can find the RFC > https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to > answer any questions as best I can. > The text uses « instead of <<, it’s confusing. It should be made clearer what #[ ] has over << >>, which does not cause any BC break. Côme -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
