# [RFC] Amendments to Attributes - Thread: https://externals.io/message/110217 - Original archive: https://news-web.php.net/php.internals/110217 - Started by Benjamin Eberlei on 2020-05-20T17:07:51+00:00 - Messages: 30 - RFC: Attribute Amendments (Implemented (PHP 8.0)) — https://externals.io/rfc/attribute_amendments.md - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/110217.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #110217 — Benjamin Eberlei — 2020-05-20T17:07:51+00:00 URL: https://externals.io/message/110217#110217 Hi everyone, the Attributes RFC was rather large already, so a few things were left open or discussions during the vote have made us rethink a things. https://wiki.php.net/rfc/attribute_amendments These points are handled by the Amendments RFC to Attributes: 1. Proposing to add a grouped syntax < 2. Rename PhpAttribute to Attribute in global namespace (independent of the namespace RFC) 3. Add validation of attribute class targets, which internal attributes can do, but userland can't 4. Specification if an attribute is repeatable or not on the same declaration and fail otherwise. Each of them is a rather small issue, so I hope its ok to aggregate all four of them in a single RFC. Please let me know if it's not. greetings Benjamin --- ## #110218 — Marco Pivetta — 2020-05-20T17:36:59+00:00 URL: https://externals.io/message/110217#110218 · In reply to: #110217 Hey Benjamin, On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei wrote: > Hi everyone, > > the Attributes RFC was rather large already, so a few things were left open > or discussions during the vote have made us rethink a things. > > https://wiki.php.net/rfc/attribute_amendments > > These points are handled by the Amendments RFC to Attributes: > > 1. Proposing to add a grouped syntax < > 2. Rename PhpAttribute to Attribute in global namespace (independent of the > namespace RFC) > 3. Add validation of attribute class targets, which internal attributes can > do, but userland can't > 4. Specification if an attribute is repeatable or not on the same > declaration and fail otherwise. > > Each of them is a rather small issue, so I hope its ok to aggregate all > four of them in a single RFC. Please let me know if it's not. > Do you hope to get nested attributes to 8.0, or is it something you'd prefer to happen at a later time? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #110219 — Larry Garfield — 2020-05-20T17:40:57+00:00 URL: https://externals.io/message/110217#110219 · In reply to: #110217 > Hi everyone, > > the Attributes RFC was rather large already, so a few things were left open > or discussions during the vote have made us rethink a things. > > https://wiki.php.net/rfc/attribute_amendments > > These points are handled by the Amendments RFC to Attributes: > > 1. Proposing to add a grouped syntax < I'm torn here. I can absolutely see the use cases for it, but it also is a can of worms in terms of many different coding styles. In short, this is going to make more work for FIG to sort out. > 2. Rename PhpAttribute to Attribute in global namespace (independent of the > namespace RFC) I don't feel strongly enough in any direction to bother wading into this... :-) > 3. Add validation of attribute class targets, which internal attributes can > do, but userland can't > 4. Specification if an attribute is repeatable or not on the same > declaration and fail otherwise. It's not clear from the RFC what the failure mode is. If I put an attribute in the wrong place, or repeat it when I shouldn't... at what point does the code blow up and how? Does it get silently skipped somewhere? Is there an exception? Is it purely informational for the user processing it? The RFC needs to be clearer on what happens when validation fails. Even if that's repeating something from the original RFC, it needs to be clarified here so that we know what we're talking about. --Larry Garfield --- ## #110220 — Ben Ramsey — 2020-05-20T17:53:37+00:00 URL: https://externals.io/message/110217#110220 · In reply to: #110217 > > > 2. Rename PhpAttribute to Attribute in global namespace (independent of the > namespace RFC) I suggested in a previous thread that we consider renaming `PhpAttribute` to `UserlandAttribute`, since this is the intent of the attribute, and it helps distinguish it from `CompilerAttribute`. I noticed that the compiler attribute is actually named `PhpCompilerAttribute`, so unless we change its name to `CompilerAttribute`, I don’t think it makes sense to change `PhpAttribute` to `Attribute`. Perhaps we change it to `PhpUserlandAttribute`, for clarity? Cheers, Ben --- ## #110221 — Benas IML — 2020-05-20T18:33:05+00:00 URL: https://externals.io/message/110217#110221 · In reply to: #110220 Hey, I personally think that `UserlandAttribute` is too verbose and a quite useless change since just using `Attribute` will make little to no BC compatibility breaks (we know that thanks to Rowan, please check out Renaming PhpAttribute thread) and would also sound more natural. This would also mean that we would rename `PhpCompilerAttribute` to simply `CompilerAttribute`. Best regards, Benas Seliuginas --- ## #110223 — Benjamin Eberlei — 2020-05-20T21:31:31+00:00 URL: https://externals.io/message/110217#110223 · In reply to: #110218 > Hey Benjamin, > > > > On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei > wrote: > > > […] > > > Do you hope to get nested attributes to 8.0, or is it something you'd > prefer to happen at a later time? > Martin evaluated the technical requirements in more detail and we discussed with others that the timeframe is probably to short to get all the details fleshed out :-( So we are going to table that for 8.1 > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ --- ## #110224 — Benas IML — 2020-05-20T21:34:44+00:00 URL: https://externals.io/message/110217#110224 · In reply to: #110223 Hello, Would it possible to make a separate RFC for renaming `PhpAttribute` to `Attribute` and `PhpCompilerAttribute` to `CompilerAttribute`? Since it would a huge BC break changing this in PHP 8.1. Best regards, Benas Seliuginas --- ## #110225 — Benjamin Eberlei — 2020-05-20T22:13:18+00:00 URL: https://externals.io/message/110217#110225 · In reply to: #110220 > > […] > the > > […] > > > I suggested in a previous thread that we consider renaming `PhpAttribute` > to `UserlandAttribute`, since this is the intent of the attribute, and it > helps distinguish it from `CompilerAttribute`. > > I noticed that the compiler attribute is actually named > `PhpCompilerAttribute`, so unless we change its name to > `CompilerAttribute`, I don’t think it makes sense to change `PhpAttribute` > to `Attribute`. Perhaps we change it to `PhpUserlandAttribute`, for clarity? > Ah that's a good point that still needs to be clarified. We realized that PhpAttribute and PhpCompilerAttribute should be merged, because the difference doesn't make a difference to userland code and it complicates things. For example enforcing that PhpCompilerAttribute is just on internal classes would not work for generated stub code in Phan/Psalm and so on that "describe" internal code by imitating it in userland. This would not be allowed by the current implementation and lead to a compiler error, lets say if we imitated Deprecated for documentation purposes: > class Deprecated {} This file could not be compiled by current implementation as an error would prevent Userland Deprecated class from using PhpCompilerAttribute. > > Cheers, > Ben --- ## #110229 — me@jhdxr.com — 2020-05-21T06:06:51+00:00 URL: https://externals.io/message/110217#110229 · In reply to: #110225 Hi Benjamin, It's good to hear that `PhpCompikerAttribute` can be merged, could you include it in the RFC as well? Thus I think people who support `UserlandAttribute` can agree with `Attribute` now as well. Regards, CHU Zhaowei -----Original Message----- From: Benjamin Eberlei Sent: Thursday, May 21, 2020 6:13 AM To: Ben Ramsey Cc: PHP Internals Subject: Re: [PHP-DEV] [RFC] Amendments to Attributes > > […] > the > > […] > > > I suggested in a previous thread that we consider renaming > `PhpAttribute` to `UserlandAttribute`, since this is the intent of the > attribute, and it helps distinguish it from `CompilerAttribute`. > > I noticed that the compiler attribute is actually named > `PhpCompilerAttribute`, so unless we change its name to > `CompilerAttribute`, I don’t think it makes sense to change > `PhpAttribute` to `Attribute`. Perhaps we change it to `PhpUserlandAttribute`, for clarity? > Ah that's a good point that still needs to be clarified. We realized that PhpAttribute and PhpCompilerAttribute should be merged, because the difference doesn't make a difference to userland code and it complicates things. For example enforcing that PhpCompilerAttribute is just on internal classes would not work for generated stub code in Phan/Psalm and so on that "describe" internal code by imitating it in userland. This would not be allowed by the current implementation and lead to a compiler error, lets say if we imitated Deprecated for documentation purposes: > class Deprecated {} This file could not be compiled by current implementation as an error would prevent Userland Deprecated class from using PhpCompilerAttribute. > > Cheers, > Ben --- ## #110234 — Ben Ramsey — 2020-05-21T15:16:28+00:00 URL: https://externals.io/message/110217#110234 · In reply to: #110229 > > > It's good to hear that `PhpCompikerAttribute` can be merged, could you include it in the RFC as well? Thus I think people who support `UserlandAttribute` can agree with `Attribute` now as well. I think I’m the only one who supports `UserlandAttribute`. :-) Yes, if these two are merged, then naming it `Attribute` is okay with me, since there won’t be any confusion with the names and naming schemes. Cheers, Ben --- ## #110244 — Nikita Popov — 2020-05-22T11:08:34+00:00 URL: https://externals.io/message/110217#110244 · In reply to: #110217 On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei wrote: > Hi everyone, > > the Attributes RFC was rather large already, so a few things were left open > or discussions during the vote have made us rethink a things. > > https://wiki.php.net/rfc/attribute_amendments > > These points are handled by the Amendments RFC to Attributes: > > 1. Proposing to add a grouped syntax < 2. Rename PhpAttribute to Attribute in global namespace (independent of the > namespace RFC) > As was mentioned in one of the previous discussions, we expect that PHP is going to ship more language-provided attributes in the future. With this proposal we have the "Attribute" attribute, but I expect we'll at least have "Deprecated" as well, and probably also something along the lines of "Jit" or "NoJit". While I'm happy with "Attribute" living in the global namespace, I don't really think we'd want to introduce "Jit" as a class in the global namespace. The name is simply to generic and does not indicate that this is part of the attribute system. We'd be forced to go with things like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to me, as we're just reinventing namespaces to avoid using them... As such, I would suggest to introduce a common namespace for all attributes provided by PHP. This means we'd have Attributes\Attribute, Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay with the PHP\Attributes\Deprecated variant, but that's a separate question). Nikita 3. Add validation of attribute class targets, which internal attributes can > do, but userland can't > 4. Specification if an attribute is repeatable or not on the same > declaration and fail otherwise. > > Each of them is a rather small issue, so I hope its ok to aggregate all > four of them in a single RFC. Please let me know if it's not. > > greetings > Benjamin --- ## #110245 — Peter Bowyer — 2020-05-22T11:55:44+00:00 URL: https://externals.io/message/110217#110245 · In reply to: #110244 > While I'm happy with "Attribute" living in the global > namespace, I don't really think we'd want to introduce "Jit" as a class in > the global namespace. The name is simply to generic and does not indicate > that this is part of the attribute system. We'd be forced to go with things > like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to > me, as we're just reinventing namespaces to avoid using them... > > As such, I would suggest to introduce a common namespace for all attributes > provided by PHP. This means we'd have Attributes\Attribute, > Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay > with the PHP\Attributes\Deprecated variant, but that's a separate > question). > This is the best real-world argument in favour of PHP namespace in core that I've heard. https://wiki.php.net/rfc/php-namespace-in-core If we don't want to introduce classes in the global namespace, it makes sense to have a reserved PHP namespace we use. Peter --- ## #110246 — Benas IML — 2020-05-22T12:19:19+00:00 URL: https://externals.io/message/110217#110246 · In reply to: #110245 Agreed. I don't think we should pollute any other than the `PHP\` namespace. If that RFC doesn't pass though, we should keep the `Attribute` class in the global namespace. Global namespace is already reserved for PHP and so, BC breaks aren't that severe whereas `Attributes\` namespace isn't reserved therefore BC breaks would be "unexpected". Best regards, Benas Seliuginas --- ## #110247 — Nikita Popov — 2020-05-22T15:28:13+00:00 URL: https://externals.io/message/110217#110247 · In reply to: #110246 > Agreed. > > I don't think we should pollute any other than the `PHP\` namespace. If > that RFC doesn't pass though, we should keep the `Attribute` class in the > global namespace. > > Global namespace is already reserved for PHP and so, BC breaks aren't that > severe whereas `Attributes\` namespace isn't reserved therefore BC breaks > would be "unexpected". > > Best regards, > Benas Seliuginas > I mean, realistically speaking, BC breaks with Attributes\Attribute are a lot less likely than with just Attribute, regardless of what we reserve or don't. Some pragmatism, please. I don't particularly care what namespace the attribute classes are under, just that they should have a common namespace, because there's going to be many of them, presumably. If it was just a matter of the Attribute class, I'd definitely say this belongs in the global namespace, but that's not what we're dealing with at this point. Nikita --- ## #110248 — Benjamin Eberlei — 2020-05-22T15:29:46+00:00 URL: https://externals.io/message/110217#110248 · In reply to: #110244 > On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei > wrote: > > > […] > > 2. Rename PhpAttribute to Attribute in global namespace (independent of the > > […] > > As was mentioned in one of the previous discussions, we expect that PHP is > going to ship more language-provided attributes in the future. With this > proposal we have the "Attribute" attribute, but I expect we'll at least > have "Deprecated" as well, and probably also something along the lines of > "Jit" or "NoJit". While I'm happy with "Attribute" living in the global > namespace, I don't really think we'd want to introduce "Jit" as a class in > the global namespace. The name is simply to generic and does not indicate > that this is part of the attribute system. We'd be forced to go with things > like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to > me, as we're just reinventing namespaces to avoid using them... > > As such, I would suggest to introduce a common namespace for all > attributes provided by PHP. This means we'd have Attributes\Attribute, > Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay > with the PHP\Attributes\Deprecated variant, but that's a separate question). > Deprecated would be an "engine level" feature, but Opcache is an extension, so it can have its own namespace "Opcache\Jit". The namespace RFC goes that far mentioning only " core symbols which cannot be unbundled" should go into a PHP namespace, which would exclude Opcache (and its "sub-extension" JIT). https://wiki.php.net/rfc/php-namespace-in-core So for me that is not necessarily an argument against Attribute in global NS, because Jit would live in Opcache\. > > Nikita > > 3. Add validation of attribute class targets, which internal attributes can > > […] --- ## #110253 — Nikita Popov — 2020-05-22T15:49:10+00:00 URL: https://externals.io/message/110217#110253 · In reply to: #110248 On Fri, May 22, 2020 at 5:29 PM Benjamin Eberlei wrote: > > > > > > […] > > Deprecated would be an "engine level" feature, but Opcache is an > extension, so it can have its own namespace "Opcache\Jit". The namespace > RFC goes that far mentioning only " core symbols which cannot be unbundled" > should go into a PHP namespace, which would exclude Opcache (and its > "sub-extension" JIT). https://wiki.php.net/rfc/php-namespace-in-core > > So for me that is not necessarily an argument against Attribute in global > NS, because Jit would live in Opcache\. > Interesting point. I think this is more an argument against using a "PHP" vendor namespace, than against using an "Attributes" namespace. JIT is not "really" an opcache feature, it just lives in opcache right now because it happens to be convenient. There are long term plans to move the optimization-related functionality from opcode into core, and JIT should also live in core (and I think there are plenty of workloads that are interested in JIT without the SHM caching). Given that context, calling the attribute Opcache\Jit seems somewhat ill-advised. I also think we'd want to provide this attribute independently of whether opcache is actually loaded, because annotating functions with it would be rather problematic if it's not always available... Ultimately I'm okay with going with just "Attribute" here, but we need to acknowledge that this comes with future obligations. In particular, introducing a "Deprecated" class is a "no" from me, because the name is too generic and does not indicate that this is part of the attribute system. It will need to be "DeprecatedAttribute" (or "Attribute_Deprecated", ugh). Which also means that you need to "use DeprecatedAttribute as Deprecated" to use it. This isn't terrible, but I also don't think it's ideal. Regards, Nikita --- ## #110263 — Jakob Givoni — 2020-05-22T20:31:13+00:00 URL: https://externals.io/message/110217#110263 · In reply to: #110247 > > I don't particularly care what namespace the attribute classes are under, > just that they should have a common namespace, because there's going to be > many of them, presumably. If it was just a matter of the Attribute class, > I'd definitely say this belongs in the global namespace, but that's not > what we're dealing with at this point. > You've made a really good argument for the \Php namespace here. I get that PHP reserves the global namespace, but I'm pretty certain that if PHP ever needs any subspaces, they should be under a common, non-global, namespace. --- ## #110265 — Bob Weinand — 2020-05-23T01:34:44+00:00 URL: https://externals.io/message/110217#110265 · In reply to: #110244 > Am 22.05.2020 um 13:08 schrieb Nikita Popov : > > On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei > wrote: > > > […] > > As was mentioned in one of the previous discussions, we expect that PHP is > going to ship more language-provided attributes in the future. With this > proposal we have the "Attribute" attribute, but I expect we'll at least > have "Deprecated" as well, and probably also something along the lines of > "Jit" or "NoJit". While I'm happy with "Attribute" living in the global > namespace, I don't really think we'd want to introduce "Jit" as a class in > the global namespace. The name is simply to generic and does not indicate > that this is part of the attribute system. We'd be forced to go with things > like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to > me, as we're just reinventing namespaces to avoid using them... > > As such, I would suggest to introduce a common namespace for all attributes > provided by PHP. This means we'd have Attributes\Attribute, > Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay > with the PHP\Attributes\Deprecated variant, but that's a separate question). > > Nikita At that point, don't we just want to be able to generically mark all attribute classes visible as being an Attribute? Also the classical examples like <> do not tell you anyhow that they're Attributes, if the class is accessed outside of attribute context. And I guess, with the logic you proposed, it will likely be named "ORM\Attribute\Entity" making it even longer. I think it would be good to be able to later on just write <>, <> etc. without further imports, as they seem to be quite basic functionality. I think it should remain possible to write simple code without much namespace awareness. Perhaps we should actually name attribute classes including their << and >>. Thus "class <> {}" (attribute decl), "new <>()" (custom instantiation), "$attribute instanceof <>". (and, for a namespaced attribute "$attribute instanceof MyNamespace\<>") The engine could quite easily support that, it's just a little parser work. That way the whole discussion as to where to put attributes in the namespace hierarchy would be quite moot, for PHP itself as well as userland. Bob P.s.: As a caveat, on parameter types, if we expect a value being of an attribute class, we'd need to require a qualified name containing at least one backslash or import-alias there. But that's acceptable I think, it will just happen within some internal attribute processing code. --- ## #110268 — Rowan Tommins — 2020-05-23T14:56:06+00:00 URL: https://externals.io/message/110217#110268 · In reply to: #110244 > As such, I would suggest to introduce a common namespace for all attributes > provided by PHP. This means we'd have Attributes\Attribute, > Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay > with the PHP\Attributes\Deprecated variant, but that's a separate question). One possible policy which came up in chat last night was that universal base classes (which tend to be few in number, and act almost as keywords) should be in the root namespace; but built-in implementations of those (at the same level as ones users could create) are prefixed with "PHP\Something\". For instance, if we had a time machine and were adding them all now: - "\Throwable" and "\Exception", but "\PHP\Exceptions\RuntimeException" - "\Iterator" but "\PHP\Iterators\FilterIterator" - "\Attribute", but "\PHP\Attributes\Deprecated" Regards, -- Rowan Tommins (né Collins) [IMSoP] --- ## #110273 — Benas IML — 2020-05-25T20:12:32+00:00 URL: https://externals.io/message/110217#110273 · In reply to: #110268 That's a brilliant idea, completely agreed, Rowan! On the other note, don't want to nitpick here but I believe that it would be better to name the repeatable attribute simply as `<>`. It would match other languages (such as Java) and the naming wouldn't be that verbose. Also IMO, I think for consistency we should either use only parameters e. g. `<>` or separate attributes for both target validation and repeatability e. g. `<>` and `<>`. Best regards, Benas Seliuginas --- ## #110289 — Benas IML — 2020-05-27T22:05:30+00:00 URL: https://externals.io/message/110217#110289 · In reply to: #110217 It seems that the RFC was updated to use the `Attributes` namespace. I think this is a bad idea since we're reserving a generic namespace that we haven't even "soft" reserved. Also, the loss of fallback to global namespace is a turning point for me. Generally, I think we should instead do something like Rowan said: use namespaced classes only for implementations (e.g. `\Attribute` but `\PHP\Deprecated`). Best regards, Benas > Hi everyone, > > the Attributes RFC was rather large already, so a few things were left open > or discussions during the vote have made us rethink a things. > > https://wiki.php.net/rfc/attribute_amendments > > These points are handled by the Amendments RFC to Attributes: > > 1. Proposing to add a grouped syntax < > 2. Rename PhpAttribute to Attribute in global namespace (independent of the > namespace RFC) > 3. Add validation of attribute class targets, which internal attributes can > do, but userland can't > 4. Specification if an attribute is repeatable or not on the same > declaration and fail otherwise. > > Each of them is a rather small issue, so I hope its ok to aggregate all > four of them in a single RFC. Please let me know if it's not. > > greetings > Benjamin --- ## #110295 — Benjamin Eberlei — 2020-05-28T17:46:55+00:00 URL: https://externals.io/message/110217#110295 · In reply to: #110289 On Thu, May 28, 2020 at 12:05 AM Benas IML wrote: > It seems that the RFC was updated to use the `Attributes` namespace. I > think this is a bad idea since we're reserving a generic namespace that we > haven't even "soft" reserved. Also, the loss of fallback to global > namespace is a turning point for me. > > Generally, I think we should instead do something like Rowan said: use > namespaced classes only for implementations (e.g. `\Attribute` but > `\PHP\Deprecated`). > I agree on sentiment, but the PHP namespace vote is failing right now, so that makes this plan just a rehashing of the existing, failing vote. The likelihood of a class Attributes\Attribute or Attributes\Deprecated existing in any code out there is much much lower, than the classes Attribute and Deprecated existing in the global namespace. The "PHP\" namespace would imply some sort of claim of the project, which the failing namespace vote shows does not exist. The way attributes map to classes, suffixes/prefixes make them strange to look at, so for future non-breaks with userland code it will be safer to put them off to a new namespace and this potentially increases the user perception. If this vote fails, this implicitly means that all future internal attributes will probably go into the global namespace. > > Best regards, > Benas > > On Wed, May 20, 2020, 8:08 PM Benjamin Eberlei > wrote: > > > […] --- ## #110323 — Theodore Brown — 2020-05-31T23:48:19+00:00 URL: https://externals.io/message/110217#110323 · In reply to: #110217 > the Attributes RFC was rather large already, so a few things were left > open or discussions during the vote have made us rethink a things. > > https://wiki.php.net/rfc/attribute_amendments > > These points are handled by the Amendments RFC to Attributes: > > 1. Proposing to add a grouped syntax < Hi Benjamin, I find the grouped attribute proposal somewhat troubling. The RFC contains the following example: ```php <> public function test() { } ``` The problem with this syntax is that adding a new attribute at the start or end of the list, or removing one of the attributes, will require modifying multiple lines. For some time the language has been moving away from this (see the various RFCs to allow trailing commas in more places), so this feels like a step backwards. If trailing commas are allowed in grouped attributes, you could write it this way instead: ```php << Attr2("foo"), Attr2("bar"), > > […] public function test() { } ``` But to me this still feels rather clunky. It requires two extra lines, and when moving from two attributes to one attribute (or vice versa), you'd still probably end up modifying multiple lines. Another issue with the grouped syntax is that comma separated attributes can be easy to confuse with comma separated attribute arguments. For example: ```php <> <> function bar() {} ``` It can be hard to tell which line contains multiple attributes vs. multiple attribute arguments. Ultimately it seems like the grouped attribute proposal is attempting to work around the poor usability of the current verbose syntax. Maybe it would be better to instead propose a simpler syntax that avoids these issues. I know that some internals members expressed interest in an `@@` token, but this was never voted on. Having a distinct token for attributes would entirely avoid the issues of having to modify multiple lines when adding/removing attributes, as well as confusion with shift operators and comma-separated attribute arguments. E.g. the RFC example would look like this instead: ```php @@Attr2("foo") @@Attr2("bar") public function test() { } ``` To me this would be a lot cleaner and fit in better with the rest of the language. Best regards, Theodore --- ## #110324 — Rowan Tommins — 2020-06-01T10:03:38+00:00 URL: https://externals.io/message/110217#110324 · In reply to: #110323 > > Having a distinct token for attributes would entirely avoid the issues > of having to modify multiple lines when adding/removing attributes, as > well as confusion with shift operators and comma-separated attribute > arguments. E.g. the RFC example would look like this instead: > > ```php > @@Attr2("foo") > @@Attr2("bar") > public function test() > { > } > ``` > I'm not sure what you mean by "having a distinct token"; the cases where there is any chance of confusion with bit-shifts are going to be very rare, and aren't related to any of the other issues you're discussing. You make some good points about not having comma-separated attributes, but they don't require us to change the syntax, just not add that feature to it. On a personal note, I find @@ a lot uglier than << and think a bracket-link syntax looks clearer when writing multiple attributes on one line to avoid long thin columns of code: <> <> public function test() { } vs @@Attr2("foo") @@Attr2("bar") public function test() { } Regards, -- Rowan Tommins [IMSoP] --- ## #110332 — Benjamin Eberlei — 2020-06-01T22:48:22+00:00 URL: https://externals.io/message/110217#110332 · In reply to: #110323 On Mon, Jun 1, 2020 at 1:48 AM Theodore Brown wrote: > On Wed, May 20, 2020 at 12:07 PM Benjamin Eberlei > wrote: > > > […] > > Hi Benjamin, > > I find the grouped attribute proposal somewhat troubling. The RFC > contains the following example: > > ```php > < Attr2("bar")>> > public function test() > { > } > ``` > > The problem with this syntax is that adding a new attribute at the > start or end of the list, or removing one of the attributes, will > require modifying multiple lines. For some time the language has been > moving away from this (see the various RFCs to allow trailing commas > in more places), so this feels like a step backwards. > > If trailing commas are allowed in grouped attributes, you could > write it this way instead: > > ```php > << > Attr2("foo"), > Attr2("bar"), > > […] > public function test() > { > } > ``` > > But to me this still feels rather clunky. It requires two extra lines, > and when moving from two attributes to one attribute (or vice versa), > you'd still probably end up modifying multiple lines. > I have added trailing commas to the attribute grouping. Now that its possible everywhere, we should go with it here directly from the beginning. About clunkyness, I am not sure this makes sense as an argument, bceause the extra lines are present for all other cases of trailing commas in popular coding styles: [ "arg1", "arg2", ] or foo( "arg1", "arg2", ); > > Another issue with the grouped syntax is that comma separated > attributes can be easy to confuse with comma separated attribute > arguments. For example: > > ```php > <> > <> > function bar() {} > ``` > > It can be hard to tell which line contains multiple attributes vs. > multiple attribute arguments. > The same is true about commas in nested short arrays. > > Ultimately it seems like the grouped attribute proposal is attempting > to work around the poor usability of the current verbose syntax. Maybe > it would be better to instead propose a simpler syntax that avoids > these issues. I know that some internals members expressed interest > in an `@@` token, but this was never voted on. > If you feel strongly about it, please create your own RFC for this. You would need to put it under discussion within this week though, as the feature freeze deadlines are looming. Personally I have no interest in opening up the syntax question again, because there are really not many objective arguments to be made, its mostly subjective and feeling based. > > Having a distinct token for attributes would entirely avoid the issues > of having to modify multiple lines when adding/removing attributes, as > well as confusion with shift operators and comma-separated attribute > arguments. E.g. the RFC example would look like this instead: > @@ is not a distinct token though, because it is already valid syntax to have the error silence operator multiple times after each other. > > ```php > @@Attr2("foo") > @@Attr2("bar") > public function test() > { > } > ``` > > To me this would be a lot cleaner and fit in better with the rest of > the language. > > Best regards, > Theodore --- Next page: https://externals.io/message/110217.md?page=2