3 years ago by Rowan Tommins — view source

unread

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

[...]

Please have a objective look at the table
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
don't just go by asthetics.

Hi Derick,

I am not a fan of the @@ syntax, and respect what you're trying to do with
this RFC, but am disappointed you haven't engaged with those of us who said
that the RFC needs more detail. There is simply not enough information in
that table to "have an objective look", and the only other text in the RFC
makes a vague assertion about the lack of ending symbol which I still don't
understand the significance of.

If I had a vote, I would vote "No" in the primary vote, not because I think
the current syntax is perfect, but because I don't think this RFC makes a
good case for a revote, and strongly suspect it will just be another beauty
contest.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Peter Bowyer — view source

unread

I am not a fan of the @@ syntax, and respect what you're trying to do with
this RFC, but am disappointed you haven't engaged with those of us who said
that the RFC needs more detail. There is simply not enough information in
that table to "have an objective look", and the only other text in the RFC
makes a vague assertion about the lack of ending symbol which I still don't
understand the significance of.

I have voted no because I asked a question about the ending delimiter and
why () didn't count. Another person asked a similar question and neither of
us got a reply.

Peter

3 years ago by Benjamin Eberlei — view source

unread

On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer phpmailinglists@gmail.com
wrote:

On Mon, 10 Aug 2020 at 10:15, Rowan Tommins rowan.collins@gmail.com
wrote:

I am not a fan of the @@ syntax, and respect what you're trying to do
with
this RFC, but am disappointed you haven't engaged with those of us who
said
that the RFC needs more detail. There is simply not enough information in
that table to "have an objective look", and the only other text in the
RFC
makes a vague assertion about the lack of ending symbol which I still
don't
understand the significance of.

I have voted no because I asked a question about the ending delimiter and
why () didn't count. Another person asked a similar question and neither of
us got a reply.

() does not count as ending symbol, because it is not required, as such its
not an ending symbol.

The point Andreas Leathley makes in the discussion thread about new Foo not
having an end symbol demonstrates exactly the opposite point he was trying
to make, because the new statement itself has to end with a semicolon:

new Foo();
new Foo;

A statement has an ending symbol semicolon.

Yes you can argue an attribute is metadata like "public" or "static" and
they don't have start and ending symbols either. But they are also single
words without special chars, as such much easier to distinguish.

The difference is also apparent in another fact: Visibility keywords are
just boolean flags on Reflection, Attributes have their own Reflection
object, they represent much more. They shouldn't be mixed up with keywords.

PHP is a language where most language constructs have ending delimiters.

Statements end in Semicolon
Function/Class/Method declarations end with a block closed by }
Argument lists end with )
Docblocks end with */
Comments always end with EOL (the distinction here being its a single end
symbol, not ambiguous)

As such for language consistency it would be better for Attributes to be
enclosed by syntax, having a start *and and ending symbol.

Peter

3 years ago by Andreas Leathley — view source

unread

() does not count as ending symbol, because it is not required, as
such its
not an ending symbol.

The point Andreas Leathley makes in the discussion thread about new Foo not
having an end symbol demonstrates exactly the opposite point he was trying
to make, because the new statement itself has to end with a semicolon:

new Foo();
new Foo;

A statement has an ending symbol semicolon.

While I don't know the exact internal semantics of PHP, according to my
grasp of the language the new keyword does not need a semicolon at the
end - it can be part of any expression, like "new Foo(new Bar);".
According to the PHP manual
(https://www.php.net/manual/en/language.basic-syntax.instruction-separation.php)
instructions in PHP need to be terminated with a semicolon, while "new"
as a keyword has no special requirement about a starting or ending
delimiter.

The point I was trying to make was that new and attributes have the same
requirements in that they both need a class name and then optionally
arguments for the constructor to that class, so they are both narrow in
terms of what they do, attributes even more so than new, which reduces
the helpfulness of delimiters as you cannot define arbitrary
instructions in attributes - it always starts off with a class and then
any possibly more complex instructions will be in the arguments, and
those are enclosed by ().

3 years ago by Rowan Tommins — view source

unread

On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer phpmailinglists@gmail.com
wrote:

I have voted no because I asked a question about the ending delimiter and
why () didn't count. Another person asked a similar question and neither
of
us got a reply.

() does not count as ending symbol, because it is not required, as such
its not an ending symbol.

The question asked was that if the parentheses were made mandatory, would
this provide the same benefits ascribed to the other syntaxes?

To avoid repeating myself, here are the previous posts where I elaborated
on this question:

Regards,

Rowan Tommins
[IMSoP]

3 years ago by guilhermeblanco@gmail.com — view source

unread

Hi,

One question I'd like answered is that, like me, a few people have
voted NO on the question to re-vote the syntax.
If that is true, shouldn't their first primary choice be implied to be
<<>> instead of anything else? I see 7 votes for no, but I'm the only
one that still kept the first voting choice as <<>>.

On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer phpmailinglists@gmail.com
wrote:

I have voted no because I asked a question about the ending delimiter and
why () didn't count. Another person asked a similar question and neither
of
us got a reply.

() does not count as ending symbol, because it is not required, as such
its not an ending symbol.

The question asked was that if the parentheses were made mandatory, would
this provide the same benefits ascribed to the other syntaxes?

To avoid repeating myself, here are the previous posts where I elaborated
on this question:

https://externals.io/message/111312#111342

https://externals.io/message/111312#111354

Regards,

Rowan Tommins
[IMSoP]

--
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

3 years ago by Benjamin Eberlei — view source

unread

On Mon, Aug 10, 2020 at 3:52 PM guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

Hi,

One question I'd like answered is that, like me, a few people have
voted NO on the question to re-vote the syntax.
If that is true, shouldn't their first primary choice be implied to be
<<>> instead of anything else? I see 7 votes for no, but I'm the only
one that still kept the first voting choice as <<>>.

At this point voting NO on the primary vote means that you are either:

are not ok with revolting this late in the release cycle
want to keep @@, because this is the current syntax (not <<>>)

On Mon, Aug 10, 2020 at 9:40 AM Rowan Tommins rowan.collins@gmail.com
wrote:

On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei kontakt@beberlei.de
wrote:

On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer <
phpmailinglists@gmail.com>
wrote:

I have voted no because I asked a question about the ending delimiter
and
why () didn't count. Another person asked a similar question and
neither
of
us got a reply.

() does not count as ending symbol, because it is not required, as such
its not an ending symbol.

The question asked was that if the parentheses were made mandatory,
would
this provide the same benefits ascribed to the other syntaxes?

To avoid repeating myself, here are the previous posts where I elaborated
on this question:

https://externals.io/message/111312#111342

https://externals.io/message/111312#111354

Regards,

Rowan Tommins
[IMSoP]

--
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

--

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Benjamin Eberlei — view source

unread

On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins rowan.collins@gmail.com
wrote:

On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei kontakt@beberlei.de
wrote:

On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer <phpmailinglists@gmail.com

wrote:

I have voted no because I asked a question about the ending delimiter
and
why () didn't count. Another person asked a similar question and neither
of
us got a reply.

() does not count as ending symbol, because it is not required, as such
its not an ending symbol.

The question asked was that if the parentheses were made mandatory, would
this provide the same benefits ascribed to the other syntaxes?

To avoid repeating myself, here are the previous posts where I elaborated
on this question:

https://externals.io/message/111312#111342

https://externals.io/message/111312#111354

For me It would indeed make a slight difference, but not wanting to speak
for Theodore, I believe he did not want to add this as another option to
vote upon, when I asked him. based on the argument that new also doesn't
require () it makes sense to me.

And for me I didn't want to add it, because then we can just go back to
<<>>, which would at least be symmetrical. I.e. @@Jit() vs <<Jit>>

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Rowan Tommins — view source

unread

On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins rowan.collins@gmail.com
wrote:

The question asked was that if the parentheses were made mandatory,
would
this provide the same benefits ascribed to the other syntaxes?

For me It would indeed make a slight difference...

Sorry, I'm as confused by this answer as I was by Derick's. Is that a "yes,
it would solve the same problems", or "it would solve some problems but not
others"?

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Derick Rethans — view source

unread

I am not a fan of the @@ syntax, and respect what you're trying to do with
this RFC, but am disappointed you haven't engaged with those of us who said
that the RFC needs more detail. There is simply not enough information in
that table to "have an objective look", and the only other text in the RFC
makes a vague assertion about the lack of ending symbol which I still don't
understand the significance of.

I have voted no because I asked a question about the ending delimiter and
why () didn't count. Another person asked a similar question and neither of
us got a reply.

I did answer that as a reply to Rowan:

https://externals.io/message/111312#111346

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

3 years ago by Peter Bowyer — view source

unread

I did answer that as a reply to Rowan:

https://externals.io/message/111312#111346

I'm with Rowan's response to you: https://externals.io/message/111312#111354

What is the difference between mandatory parentheses giving:

<<symbol>><<attribute-name>>(
<<symbol>><<attribute-name2>>(<<arg1>>),
42
)

and:

<<symbol>>[<<attribute-name>>(
<<symbol>>[<<attribute-name2>>(<<arg1>>)],
42
)]

in terms of parsing, use etc.

Peter

3 years ago by Peter Bowyer — view source

unread

On Mon, 10 Aug 2020 at 15:41, Peter Bowyer phpmailinglists@gmail.com
wrote:

I did answer that as a reply to Rowan:

https://externals.io/message/111312#111346

I'm with Rowan's response to you:
https://externals.io/message/111312#111354

What is the difference between mandatory parentheses giving:

<<symbol>><<attribute-name>>(
<<symbol>><<attribute-name2>>(<<arg1>>),
42
)

and:

<<symbol>>[<<attribute-name>>(
<<symbol>>[<<attribute-name2>>(<<arg1>>)],
42
)]

in terms of parsing, use etc?

Peter

Anyone?

Why is the discussion fixated on [] rather than ()?

Peter

3 years ago by Rowan Tommins — view source

unread

On Tue, 11 Aug 2020 at 14:15, Peter Bowyer phpmailinglists@gmail.com
wrote:

Anyone?

Why is the discussion fixated on [] rather than ()?

Elsewhere, Derick clarified that he sees a "conceptual/logical" difference
between brackets around just the argument list and the brackets around the
whole expression, rather than anything concrete to do with parsing.

I suspect this is a mental bias because we're used to pairing off ( and )
or [ and ]. If we imagine a straw man syntax with no brackets of any sort:

~~AttributeName:param1,param2!

I think everyone would agree that the "!" here ended the attribute
declaration, not just the parameter list. But looking closely, that's a
one-to-one substitution from @@ with mandatory parens:

~~ <name> : <argument-list> !
@@ <name> ( <argument-list> )

That doesn't mean it's wrong to say there's a different feeling between the
two, but does highlight that like every other factor discussed, this is
basically a subjective feeling, rather than anything substantial.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Benjamin Eberlei — view source

unread

On Mon, Aug 10, 2020 at 11:16 AM Rowan Tommins rowan.collins@gmail.com
wrote:

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

[...]

Please have a objective look at the table
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
don't just go by asthetics.

Hi Derick,

I am not a fan of the @@ syntax, and respect what you're trying to do with
this RFC, but am disappointed you haven't engaged with those of us who said
that the RFC needs more detail. There is simply not enough information in
that table to "have an objective look", and the only other text in the RFC
makes a vague assertion about the lack of ending symbol which I still don't
understand the significance of.

If I had a vote, I would vote "No" in the primary vote, not because I think
the current syntax is perfect, but because I don't think this RFC makes a
good case for a revote, and strongly suspect it will just be another beauty
contest.

I am sorry this was a misunderstanding between Derick and I. I had worked
on the more detail already, but we had a miscommunication about updating
the RFC. I add my notes in a few minutes, sorry :-(

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Jordi Boggiano — view source

unread

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

Here is a more detailed comparison of how this would look like in real
use, adapted from some basic doctrine and symfony validation annotation
I got somewhere:

https://gist.github.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c

I think something like this would belong in the RFC. I find that the
grouping "feature" does not help that much, it's kinda hard to grasp
what's going on. Proper syntax highlighting would surely help but still.

You may argue it's comparing in terms of looks, but as others have said
I find it hard to compare them in other terms as the pros/cons listed in
the RFC have a very limited impact for the most part, so yeah I feel
like looks and readability should be at least somewhat taken into
account too.

Best,
Jordi

3 years ago by Markus Fischer — view source

unread

https://gist.github.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c

This is really really useful!

However I suggest to look at the raw text rather, because the
highlighting is unaware of the syntax and may bias "how it feels to look
at it" (*):

https://gist.githubusercontent.com/Seldaek/b7a3bd28920c6cc181e67a829b13a81c/raw/ccb612d2547c99fe69d1bf09138efae22b956b37/attributes.php

Personally, and never gave it much thought TBH, the @@ AND <</>>
in fact is the most "unreadable" version to me because duplicate
occurrence of a single character somehow creates a noise for me,

I don't feel eligible to have a vote, but based on that and certainly
aware IDEs in the future will help with this, I would vote for
anything not duplicating characters, i.e. favoring #[] or @[]

:-}

Markus

(*) Apologies for lack of words trying to describe my thoughts

3 years ago by Andreas Leathley — view source

unread

Personally, and never gave it much thought TBH, the @@ AND <</>>
in fact is the most "unreadable" version to me because duplicate
occurrence of a single character somehow creates a noise for me,

I don't feel eligible to have a vote, but based on that and certainly
aware IDEs in the future will help with this, I would vote for
anything not duplicating characters, i.e. favoring #[] or @[]

It is a pity that syntax with ending delimiters and syntax with no
ending delimiters are now mixed in the discussion, instead of first
finding a concensus if delimiters are even needed or what
advantages/disadvantages they have. Because there are many alternatives
in terms of syntax - looking back at the very first vote about
attributes the @: syntax doesn't seem so bad, if no ending delimiters
are needed. In the new RFC all alternatives to @@ have delimiters and it
is suggested having them is good, yet the possible advantages of
delimiters are never explained, ideally with some real-world examples
showing why delimiters would be good to have.

3 years ago by Derick Rethans — view source

unread

Personally, and never gave it much thought TBH, the @@ AND <</>>
in fact is the most "unreadable" version to me because duplicate
occurrence of a single character somehow creates a noise for me,

I don't feel eligible to have a vote, but based on that and certainly
aware IDEs in the future will help with this, I would vote for
anything not duplicating characters, i.e. favoring #[] or @[]

It is a pity that syntax with ending delimiters and syntax with no
ending delimiters are now mixed in the discussion, instead of first
finding a concensus if delimiters are even needed or what
advantages/disadvantages they have.

It missing an ending delimiter was my first reason for wanting to get
something better than @@. I don't particularly care much if it ends up
being @[], #[], <<>>, or other things such as @:( ).

In my original email, I solicited other syntaxes (with patches), but
none were brought up.

Because there are many alternatives in terms of syntax - looking back
at the very first vote about attributes the @: syntax doesn't seem so
bad, if no ending delimiters are needed. In the new RFC all
alternatives to @@ have delimiters and it is suggested having them is
good, yet the possible advantages of delimiters are never explained,
ideally with some real-world examples showing why delimiters would be
good to have.

If you have something to open, and close, there there is a distinct area
that forms the whole definition of a thing. That's why functions, and
classes have { and }, if and other control structures have ( .. ), etc.

Being able to define a whole "thing" easily with an open and closing set
of symbols, allows for better mental parsing. It also means that syntax
highlighting tools can map the opening part with the closing part. (VIM
for example, uses the % character to jump between opening and closing
symbol).

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

3 years ago by Andreas Leathley — view source

unread

It missing an ending delimiter was my first reason for wanting to get
something better than @@. I don't particularly care much if it ends up
being @[], #[], <<>>, or other things such as @:( ).

If you have something to open, and close, there there is a distinct area
that forms the whole definition of a thing. That's why functions, and
classes have { and }, if and other control structures have ( .. ), etc.

Being able to define a whole "thing" easily with an open and closing set
of symbols, allows for better mental parsing. It also means that syntax
highlighting tools can map the opening part with the closing part. (VIM
for example, uses the % character to jump between opening and closing
symbol).

For me the difference would be that with attributes, you are not opening
and closing many possible statements, it can only be one (or more, with
grouping) class name(s), which then can have arguments, but those are
enclosed with (). In comparison, classes can have many possible
definitions inside of them (class variables, methods, constants, etc.),
so enclosing them clearly makes sense, as you need to know where it
ends. The same goes for if, for, while, etc.

So if you just have one class name as an attribute, enclosing it seems a
bit overkill, as there is already a definition of a class name and how
it starts and ends, which is why for me the mental parsing does not seem
easier - but what is easily parseable probably depends on many factors
and might be different for different people.

I would have found a syntax where the delimiters are optional preferable

similar to "if", where you can leave off the {} for exactly one
instruction, but you have to add them if there is more than one line of
instructions. Or the group use syntax.

3 years ago by Theodore Brown — view source

unread

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The first vote is a vote to say that you have an opinion about attribute
syntax. Make sure to read up on the discussion on the mailinglist if you
haven't done so yet.

I voted "No", as the primary premise for this RFC is fundamentally flawed:

The main concern is that @@ has no ending symbol and it's inconsistent
with the language that it would be the only declaration or statement
in the whole language that has no ending termination symbol.

As I pointed out in the discussion thread, this simply is not the case.
Attributes are not standalone declarations or statements, but modifiers
that always come before a declaration and add metadata to it. This
is consistent with visibility modifiers and type declarations (which
are not necessarily a single word):

# declaration modifiers do not have end/grouping symbols like this
@[MyAttr([1, 2])]
[public] function foo(@[Deprecated] [int|float] $bar) {}

# this is more consistent:

@@MyAttr([1, 2])
public function foo(@@Deprecated int|float $bar) {}

The second vote is an STV vote.

In STV you SHOULD rank all choices, but don't pick the same one more
than once, as that will invalidate your vote.

Please have a objective look at the table
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
don't just go by asthetics.

I find this table to be unfortunately incomplete. E.g. why doesn't it
bold the number of required characters for @@, since this is one of
its advantages? And why is "Allows Grouping" marked as an advantage
for the other three syntaxes? Grouping adds implementation complexity,
leads to unnecessary diff noise, and is rarely more concise than @@ in
real-world use cases.

I also find it concerning that the RFC doesn't have an example for each
consideration showing how one syntax addresses it better than another.
For example, the Shorter Attribute Syntax RFC showed potential nested
attributes and how @@ would support them more cleanly, but this RFC
fails to mention them anywhere.

Finally, while the table mentions that each syntax other than <<>> has
a BC break, I think it's just as important to consider the size of
the breaking change. #[] and @[] are larger BC breaks than @@ since
they break useful syntax:

// with #[]
#[x] code like this would break
$val = ['new value']; #['old value'];

// with @[]
$x = @[foo(), bar()]; // this code would break

Both of these are useful patterns, and I'm not convinced that breaking
them is justified. Shouldn't there be a Backward Incompatible Changes
section in the RFC with these examples?

Best regards,
Theodore

3 years ago by Benas IML — view source

unread

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The first vote is a vote to say that you have an opinion about attribute
syntax. Make sure to read up on the discussion on the mailinglist if you
haven't done so yet.

I voted "No", as the primary premise for this RFC is fundamentally flawed:

The main concern is that @@ has no ending symbol and it's inconsistent
with the language that it would be the only declaration or statement
in the whole language that has no ending termination symbol.

As I pointed out in the discussion thread, this simply is not the case.
Attributes are not standalone declarations or statements, but modifiers
that always come before a declaration and add metadata to it. This
is consistent with visibility modifiers and type declarations (which
are not necessarily a single word):
# declaration modifiers do not have end/grouping symbols like this
@[MyAttr([1, 2])]
[public] function foo(@[Deprecated] [int|float] $bar) {}

# this is more consistent:

@@MyAttr([1, 2])
public function foo(@@Deprecated int|float $bar) {}
The second vote is an STV vote.

In STV you SHOULD rank all choices, but don't pick the same one more
than once, as that will invalidate your vote.

Please have a objective look at the table
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
don't just go by asthetics.

I find this table to be unfortunately incomplete. E.g. why doesn't it
bold the number of required characters for @@, since this is one of
its advantages? And

IMO there's literally no advantage in typing one less character. Because if
there is, let's also shorten all of our function names i. e. strlen to
sl and gettype to gt.

why is "Allows Grouping" marked as an advantage

for the other three syntaxes? Grouping adds implementation complexity,
leads to unnecessary diff noise, and is rarely more concise than @@ in
real-world use cases.

I'd like to remind other internals that there is no "added complexity"
(unless someone is unable to understand 20 lines of code) and it's
misleading to say otherwise.

I also find it concerning that the RFC doesn't have an example for each
consideration showing how one syntax addresses it better than another.
For example, the Shorter Attribute Syntax RFC showed potential nested
attributes and how @@ would support them more cleanly, but this RFC
fails to mention them anywhere.

Syntax choice DOES NOT affect how "cleanly" we can support nested
attributes. AFAIK simple recursion would allow to implement those with any
attribute syntax with exactly the same code.

Finally, while the table mentions that each syntax other than <<>> has
a BC break, I think it's just as important to consider the size of
the breaking change. #[] and @[] are larger BC breaks than @@ since
they break useful syntax:
// with #[]
#[x] code like this would break
$val = ['new value']; #['old value'];

// with @[]
$x = @[foo(), bar()]; // this code would break
Both of these are useful patterns, and I'm not convinced that breaking
them is justified. Shouldn't there be a Backward Incompatible Changes
section in the RFC with these examples?

Best regards,
Theodore

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Chris Riley — view source

unread

Hi,

Quick question.

What is the expected behaviour of:

@[Bar()];
class Foo {}

That would appear to be valid code and for the difference of a single ;
does wildly different things, assuming there is a function Bar defined
somewhere. (and only by the fact that @ doesn't suppress fatal errors does
it not cause utter confusion if Bar isn't defined)

Regards,
Chris

Hi,

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The first vote is a vote to say that you have an opinion about attribute
syntax. Make sure to read up on the discussion on the mailinglist if you
haven't done so yet.

The second vote is an STV vote.

In STV you SHOULD rank all choices, but don't pick the same one more
than once, as that will invalidate your vote.

Please have a objective look at the table
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
don't just go by asthetics.

The vote ends August 23, 24:00 UTC.

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

--

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Matteo Beccati — view source

unread

Hi,

What is the expected behaviour of:

@[Bar()];
class Foo {}

That would appear to be valid code and for the difference of a single ;
does wildly different things, assuming there is a function Bar defined
somewhere. (and only by the fact that @ doesn't suppress fatal errors does
it not cause utter confusion if Bar isn't defined)
I think an 'unexpected token ";"', which is what currently happens if
you do the same with "@@" on current master, would still be an
appropriate behaviour.

FWIW, I haven't made up my mind yet and that's why I haven't cast my
vote yet.

I do agree with Chris here and I somehow mentally parse the above as
"silencing an array containing a function call", which to me is bad
enough to rule the syntax out. I would surely get used to it, if
accepted, but that's how I feel now.

Rust's #[] to me looks better, but I am still bothered by the fact that
it can be used in a backwards compatible way, but not fully so
(multi-line, syntax errors).

And "@@" is super ugly, although I'm not bothered that much by its lack
of ending delimiter, since most of the times longer attributes will
still, albeit just visually, have some in the closing ")".

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

3 years ago by Chris Riley — view source

unread

Hi,

What is the expected behaviour of:

@[Bar()];
class Foo {}

That would appear to be valid code and for the difference of a single ;
does wildly different things, assuming there is a function Bar defined
somewhere. (and only by the fact that @ doesn't suppress fatal errors
does
it not cause utter confusion if Bar isn't defined)
I think an 'unexpected token ";"', which is what currently happens if
you do the same with "@@" on current master, would still be an
appropriate behaviour.

FWIW, I haven't made up my mind yet and that's why I haven't cast my
vote yet.

I do agree with Chris here and I somehow mentally parse the above as
"silencing an array containing a function call", which to me is bad
enough to rule the syntax out. I would surely get used to it, if
accepted, but that's how I feel now.

Rust's #[] to me looks better, but I am still bothered by the fact that
it can be used in a backwards compatible way, but not fully so
(multi-line, syntax errors).

And "@@" is super ugly, although I'm not bothered that much by its lack
of ending delimiter, since most of the times longer attributes will
still, albeit just visually, have some in the closing ")".

Cheers

Matteo Beccati

Development & Consulting - http://www.beccati.com/

My concern wasn't so much of mentally parsing it as a silenced function
call in an array; more that PHP currently parses it that way. That example
becoming invalid code would be a reasonable option, but leaving it as valid
code just sets people up to spend ages hunting a "why is this annotation
not being applied to my class bug". (and before anyone says this won't
happen; I have spent hours in the past tracking down missing annotations
which occured because of the difference between /* and /**)

For the record, my preference is @[ ], I just also like removing as many
potential cases of debugging stupid issues as possible.

~C

3 years ago by Derick Rethans — view source

unread

Quick question.

What is the expected behaviour of:

@[Bar()];
class Foo {}

That will error out in PHP 8, with:

Parse error: syntax error, unexpected token ";" in Standard input code on line 2

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

3 years ago by Chris Riley — view source

unread

Quick question.

What is the expected behaviour of:

@[Bar()];
class Foo {}

That will error out in PHP 8, with:

Parse error: syntax error, unexpected token ";" in Standard input code on
line 2

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

Is

<?php @[Bar()]; ?>

on it's own an error?

3 years ago by Theodore Brown — view source

unread

Quick question.

What is the expected behaviour of:

@[Bar()];
class Foo {}

That will error out in PHP 8, with:

Parse error: syntax error, unexpected token ";" in Standard input code on
line 2

Is

<?php @[Bar()]; ?>

on it's own an error?

Yes. Basically this is an example of valid code in PHP 7 that will
break if @[] is adopted. However, it will remain valid to write the
following:

@ [Bar()]; // suppressed function call
@[ Bar() ] // attribute
class Foo {}

Is this still confusing? I think so. People could easily expect
that the first line is an attribute, or that attributes should
be followed by a semicolon since they have an ending bracket.

This could even make it easier to sneak vulnerabilities into PHP
projects. :\

A second downside of @[] that doesn't appear to have been discussed
yet is typability. On my keyboard, it requires four different keys
on different sides of the keyboard, whereas @@ just requires two keys.

Thirdly, the @[] syntax with grouping removes the ability to easily
grep for attributes, which was one of the benefits of @@ mentioned in
the Shorter Attribute Syntax RFC.

Unfortunately, this new RFC fails to mention any of these issues,
thus presenting an incomplete picture of the pros and cons which
appears to be influencing the vote results against @@.

@[] has had relatively little discussion compared to the other syntax
options so far, and not all of its issues may even be known yet.

Best regards,
Theodore

3 years ago by Lynn — view source

unread

On Tue, Aug 11, 2020 at 3:03 PM Theodore Brown theodorejb@outlook.com
wrote:

A second downside of @[] that doesn't appear to have been discussed
yet is typability. On my keyboard, it requires four different keys
on different sides of the keyboard, whereas @@ just requires two keys.

If typability really matters, we should've deprecated the backtick version
to run things. We also seem to forget about readability. @@ makes things
really hard to read for me as it draws attention, the same goes for <<and>>
being written as such, with spaces it's fine. In terms of @[] typability,
my IDE auto completes the ] when I type [. After that we have to type a
word which will most likely require keys on the right side of the keyboard
anyway. Sure, typing @@ is easier, for me this is at the cost of
readability. I read code more frequently than I write it, so I think this
should matter more.

Please don't use @@ for annotations/attributes.

3 years ago by Rowan Tommins — view source

unread

In terms of @[] typability, my IDE auto completes the ] when I type [.

I really, really, hate when editors and IDEs do that, and switch off every
variant of it I can find in the settings. Either it will get it wrong
because I'm editing code not writing from scratch; or it will get it right
but I'll type the punctuation myself before I notice that; in both cases,
it takes more effort to type with that feature than without it.

As far as the UK keyboard layout's concerned, all four of the options in
this week's list use buttons to the right of the letters, although #[] is
the only one that doesn't need any use of shift. Which mostly just goes to
show that pretty much any punctuation will be hard to type on some layouts
and easy on others.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Andreas Leathley — view source

unread

If typability really matters, we should've deprecated the backtick
version
to run things. We also seem to forget about readability. @@ makes things
really hard to read for me as it draws attention, the same goes for <<and>>
being written as such, with spaces it's fine. In terms of @[] typability,
my IDE auto completes the ] when I type [. After that we have to type a
word which will most likely require keys on the right side of the keyboard
anyway. Sure, typing @@ is easier, for me this is at the cost of
readability. I read code more frequently than I write it, so I think this
should matter more.

Please don't use @@ for annotations/attributes.

I do understand that not everyone likes @@ in terms of perceived
readability, although in IDEs this will probably be less of a problem
(by making @@ less noticeable in terms of colors and contrast).

It seems unfortunate to me that this RFC just seems super hasty in terms
of unfinished discussions and in that it mixes very different concerns -
an ending delimiter is made out to be necessary in terms of language,
although that seems contentious at best and would be something to agree
on first, separate of the actual syntax and how it looks and feels. And
if someone does not like @@ yet would like a different syntax with no
delimiters, there is no choice for that. The @[] syntax is very last
minute, and including the original choice of @: would have also been an
option: at the time it lost against <<>>, but after that <<>> lost
against @@, so the choices in the RFC are obviously chosen to make sure
a syntax with delimiters is chosen, yet sacrificing a proper discussion
(and enable people to think about it more) because of the time
constraints - instead of just delaying it for 8.1 and having the
necessary time to get to the best possible solution.

Just compare the previous RFCs about the attribute feature and syntax
and the current one - the current one does not even explain the BC
breaks the different syntaxes produce, which was otherwise always one of
the more important parts of an RFC, so at best the RFC is incomplete in
terms of its information. As far as I can tell almost none of the
suggestions to amend the RFCs have been taken into account, so the
original discussion about it seems to have been pointless. I am a bit
disappointed to see this kind of process in PHP, especially
"last-minute" before a new major release.

3 years ago by Derick Rethans — view source

unread

A second downside of @[] that doesn't appear to have been discussed
yet is typability. On my keyboard, it requires four different keys on
different sides of the keyboard, whereas @@ just requires two keys.

They're the same on a US English/US International keyboard, both 4
presses:

For @@: Shift 2 Shift 2
For @[]: Shift 2 [ ]

In the case of @[], an IDE likely will automatically add the
closing ].

Additionally, on a US English/US International keybaord, Shift-2 (for @)
is an awkward combination to type with the pinky and middle finger of
your left hand.

On a UK English, it's the same amount, with the @ a little easier than
on a US English one, with: left-shift @/' [ ]

So if you want to add typeability to the matrix, I can do that, but @@
comes out worse.

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

3 years ago by Theodore Brown — view source

unread

A second downside of @[] that doesn't appear to have been discussed
yet is typability. On my keyboard, it requires four different keys on
different sides of the keyboard, whereas @@ just requires two keys.

They're the same on a US English/US International keyboard, both 4
presses:

For @@: Shift 2 Shift 2
For @[]: Shift 2 [ ]

In the case of @[], an IDE likely will automatically add the
closing ].

Additionally, on a US English/US International keybaord, Shift-2 (for @)
is an awkward combination to type with the pinky and middle finger of
your left hand.

On a UK English, it's the same amount, with the @ a little easier than
on a US English one, with: left-shift @/' [ ]

So if you want to add typeability to the matrix, I can do that, but @@
comes out worse.

How does @@ come out worse?

For @@: Shift, double-@
For @[]: Shift, @, left bracket

Even if your IDE autocompletes the closing bracket, @@ is faster to
type than @[] on common qwerty layouts. Also, it is easier to mistype
@[ as @] (I kept doing this multiple times when typing this reply).

Anyway, please do add easy typeability to the matrix, along with the
fact that the @@ syntax makes attributes easier to grep for. These
should have been in the matrix from the start, given that both were
mentioned as factors in the Shorter Attribute Syntax RFC.

When I originally wrote the Shorter Attribute Syntax RFC, I wasn't
aware that it was allowed to re-vote on failed syntax options without
waiting at least 6 months. Otherwise I would have included an option
to re-vote for the @: syntax.

Since apparently this is allowed now, can we also add @: as a voting
option? I have a patch for it here: https://github.com/theodorejb/php-src/pull/1

It seems pretty clear that the vote should be restarted anyway,
given that the RFC has already been heavily edited multiple times
after the voting started.

Kind regards,
Theodore

3 years ago by Rowan Tommins — view source

unread

How does @@ come out worse?

Seems clear enough to me:

Additionally, on a US English/US International keybaord, Shift-2 (for @)
is an awkward combination to type with the pinky and middle finger of
your left hand.

(Note that this is also true of UK Mac keyboards, which more closely
resemble the US PC layout.)

Anyway, please do add easy typeability to the matrix

How would you measure "easy typability"? On what keyboard layout? Would you
write "Yes" and "No", or "quite easy", or marks out of 10?

fact that the @@ syntax makes attributes easier to grep for.

The same question: how do you summarise this in a table? Complexity of the
regex? Number of false positives in some representative code base?

As I've said before, the table would be useful if it was a re-cap of
arguments discussed in prose elsewhere, but it is not on its own a good
source of information for making a decision.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Theodore Brown — view source

unread

Anyway, please do add easy typeability to the matrix

How would you measure "easy typability"? On what keyboard layout?
Would you write "Yes" and "No", or "quite easy", or marks out of 10?

Hi Rowan,

I would suggest "Kinds of symbols used".

@@ is easier since it only uses one kind of symbol, rather than
switching between two or three symbols which are often on different
sides of the keyboard.

fact that the @@ syntax makes attributes easier to grep for.

The same question: how do you summarise this in a table? Complexity
of the regex? Number of false positives in some representative code
base?

This can be a simple Yes or No. With @@ or @: you can type those
symbols followed by the attribute name to grep for it. With the other
syntaxes and attribute grouping, if the name isn't unique it may be
difficult to search for since you can't rely on a unique leading symbol.

As I've said before, the table would be useful if it was a re-cap of
arguments discussed in prose elsewhere, but it is not on its own a good
source of information for making a decision.

Generally I agree, the table is not particularly helpful in making a
decision here.

Regards,
Theodore

3 years ago by Rowan Tommins — view source

unread

I would suggest "Kinds of symbols used".

@@ is easier since it only uses one kind of symbol, rather than
switching between two or three symbols which are often on different
sides of the keyboard.

Honestly, this feels about as objective as "number of pixels" - feel free
to use it your own vote, but it doesn't feel headline-worthy.

fact that the @@ syntax makes attributes easier to grep for.

This can be a simple Yes or No. With @@ or @: you can type those
symbols followed by the attribute name to grep for it. With the other
syntaxes and attribute grouping, if the name isn't unique it may be
difficult to search for since you can't rely on a unique leading symbol.

Surely all of the syntaxes will be easily greppable once adopted, because
any instances that aren't attributes will have to be fixed (other than
those in comments and strings, which can happen with any of them).

Any of these will show up very little outside attributes once you've fixed
parse errors:

#[
@[
@:
@@

"<<" is possibly an outlier here IF you use bit shifts a lot.

To filter further, you can write a quick regex to match the attribute name;
untested, but something like:

/#[[A-Za-z0-9\]+[(]]/
/@[[A-Za-z0-9\]+[(]]/
/@:[A-Za-z0-9\]+/
/@@[A-Za-z0-9\]+/
/<<[A-Za-z0-9\]+(>>|()/

That last one has a small chance of matching something like "$foo =
$bar<<getShiftSize();" which might be annoying if you use bitshifts a lot
AND don't put spaces around operators.

So, sure, <<Foo>> has a small disadvantage here, but it's also been
thoroughly rejected in a previous vote, and seems unlikely to suddenly make
a comeback.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Theodore Brown — view source

unread

fact that the @@ syntax makes attributes easier to grep for.

This can be a simple Yes or No. With @@ or @: you can type those
symbols followed by the attribute name to grep for it. With the other
syntaxes and attribute grouping, if the name isn't unique it may be
difficult to search for since you can't rely on a unique leading symbol.

Surely all of the syntaxes will be easily greppable once adopted, because
any instances that aren't attributes will have to be fixed (other than
those in comments and strings, which can happen with any of them).

I think you may have misunderstood my point - it's not so much about
the leading symbols but about grouping. Consider the following example:

@[
    Jit,
    Route("/api/posts/{id}", methods: ["GET", "HEAD"]),
]
public function show(int $id) { ... }

What will you grep for if you want to find all places where the Route attribute is used (but not some other class named Route)?

With the @@ syntax you can easily grep for "@@Route" to find all the
places where specifically the attribute is used:

@@Jit
@@Route("/api/posts/{id}", methods: ["GET", "HEAD"])
public function show(int $id) { ... }

Best regards,
Theodore

3 years ago by Rowan Tommins — view source

unread

I think you may have misunderstood my point - it's not so much about
the leading symbols but about grouping.

That sounds like a reason to vote No to grouping, which you already did:
https://wiki.php.net/rfc/attribute_amendments#group_statement_for_attributes1

What will you grep for if you want to find all places where the Route
attribute is used (but not some other class named Route)?

With any syntax, you can't exclude other classes named Route which are also
being used as annotations. If you want things to be easy to tell apart,
don't call them the same thing.

If you specifically want annotations to stand out, name or alias all
annotations as "RouteAnnotation" or "ARoute" or something.

For that matter, just make a coding standard in your project to never use
grouped attributes, or always use fully-qualified names in attributes...

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Larry Garfield — view source

unread

What will you grep for if you want to find all places where the Route
attribute is used (but not some other class named Route)?

I'd go to the Route attribute class in my IDE, right click, and select "find usages."

I'll be honest, 75% of the points made in this thread seem spurious to me, regardless of which syntax they're supporting. (FTR, I don't have an especially strong opinion either way other than marginally liking having a closing sigil.)

For the BC potential of #[], as a library author it doesn't make much difference to me. I will likely add attribute support to Tukio soon after PHP 8 is released, but I'll just be reading from the Reflection API if available, in addition to the existing mechanisms I have in place. Which syntax a given listener uses (<<>>, @@, @[], #[], etc.) doesn't matter at that point, only the reflection API does. So opt-in attribute support can happen regardless of the syntax.

(I know, I'm one of the people who pointed out the BC potential of #[] previously, but at least for the use cases i can foresee it's not actually relevant.)

--Larry Garfield

3 years ago by Jakob Givoni — view source

unread

Quick question.

What is the expected behaviour of:

@[Bar()];
class Foo {}

That will error out in PHP 8, with:

Parse error: syntax error, unexpected token ";" in Standard input code on
line 2

Is

<?php @[Bar()]; ?>

on it's own an error?

Yes. Basically this is an example of valid code in PHP 7 that will
break if @[] is adopted.

Wow, that was unexpected. By what logic?
Also, how long must I wait before I can put a semicolon after the new
attribute syntax? Is one whitespace enough or do I have to go to a new
line?
To me, suddenly disallowing semicolons at some points between
statements or between a "declaration" and a statement seems to break
PHP logic.

Are there any precedents for this that I've missed?

Best,
Jakob

3 years ago by Rowan Tommins — view source

unread

Is

<?php @[Bar()]; ?>

on it's own an error?

Yes. Basically this is an example of valid code in PHP 7 that will
break if @[] is adopted.

Wow, that was unexpected. By what logic?
Also, how long must I wait before I can put a semicolon after the new
attribute syntax? Is one whitespace enough or do I have to go to a new
line?
To me, suddenly disallowing semicolons at some points between
statements or between a "declaration" and a statement seems to break
PHP logic.

It's not that the semicolon is forbidden as such, it's that the code is interpreted completely differently.

Imagine if we had no "private" keyword, and then added it; this would previously have been valid (a statement followed by a declaration):

private; function foo () {}

But once "private" is a keyword, that is a syntax error.

Removing the semicolon happens to make a valid declaration using the keyword, but that's basically coincidence:

private function foo() {}

The same is true of attributes, which as others have pointed out are similar to visibility or scope modifiers - anywhere that could be an attribute will be parsed as one, not as a statement, comment, or whatever else, so some code changes meaning, and other code becomes a syntax error.

Regards,

--
Rowan Tommins
[IMSoP]

3 years ago by Jakob Givoni — view source

unread

Is

<?php @[Bar()]; ?>

on it's own an error?

Yes. Basically this is an example of valid code in PHP 7 that will
break if @[] is adopted.

Wow, that was unexpected. By what logic?
Also, how long must I wait before I can put a semicolon after the new
attribute syntax? Is one whitespace enough or do I have to go to a new
line?
To me, suddenly disallowing semicolons at some points between
statements or between a "declaration" and a statement seems to break
PHP logic.

It's not that the semicolon is forbidden as such, it's that the code is interpreted completely differently.

Imagine if we had no "private" keyword, and then added it; this would previously have been valid (a statement followed by a declaration):

private; function foo () {}

Ok, that's starting to make sense. Having seen so many attribute
examples lately I started to get the impression that you could
basically insert them anywhere (like comments) - even if it didn't
technically make any sense... Reading the original RFC again I
understand that an attribute MUST be directly followed by a function,
class, interface, traits, class constant, class property, class
method, function/method parameter, a docblock or another attribute. I
hope I didn't forget anything... Sorry, I'm just a sucker for details
and accuracy :-)

Thanks,
Jakob

3 years ago by Sara Golemon — view source

unread

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

Just chiming in to say all, y'all voting for @[...] are making a terrible
choice, and are you sure you're okay with it?

We have options with varying degrees of backward compatibility issues (<<>>
none, @@ some, #[..] and @[..] a bit more than some), and only one which
offers forward compatibility (#[..]).
So why vote in favor of the option with the highest BC breaking probability
and no FC?

Thank you for coming to my TED talk.

-Sara

3 years ago by guilhermeblanco@gmail.com — view source

unread

Hi Sara,

I'd like to explain my rationale. Most of the time I end up using
"#[todo] Whatever" while documenting my code... my intentions are "#
[todo] ...", but you know... missing that space char doesn't break
anything today...
In any case, BC is broken and FC would also not work. Now I assume
it's a quite rare scenario where someone is doing: @[...] where
suppressing is needed, especially when we check against the #[...]
case.

Cheers,

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

Just chiming in to say all, y'all voting for @[...] are making a terrible
choice, and are you sure you're okay with it?

We have options with varying degrees of backward compatibility issues (<<>>
none, @@ some, #[..] and @[..] a bit more than some), and only one which
offers forward compatibility (#[..]).
So why vote in favor of the option with the highest BC breaking probability
and no FC?

Thank you for coming to my TED talk.

-Sara

--
Guilherme Blanco
SVP Technology at Statflo Inc.
Mobile: +1 647 232 5599

3 years ago by Rowan Tommins — view source

unread

On Tue, 11 Aug 2020 at 16:07, guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

I'd like to explain my rationale. Most of the time I end up using
"#[todo] Whatever" while documenting my code... my intentions are "#
[todo] ...", but you know... missing that space char doesn't break
anything today...
In any case, BC is broken and FC would also not work. Now I assume
it's a quite rare scenario where someone is doing: @[...] where
suppressing is needed, especially when we check against the #[...]
case.

This feels a bit arbitrary to me: the way you've worded it here makes it
sound like because you use one and not the other, you've assumed that one
is more common than the other.

I've personally never used either, but can see situations where both would
arise, and have absolutely no idea which is more common, and what the
impact would be.

My vote, if I had one, would remain under "No" for this re-vote. There
seems to be no reason to allow this vote, but not allow another one next
week with a new suggestion, and nothing objective to choose between the
syntaxes.

Regards,

Rowan Tommins
[IMSoP]

3 years ago by Sara Golemon — view source

unread

On Tue, Aug 11, 2020 at 10:07 AM guilhermeblanco@gmail.com <
guilhermeblanco@gmail.com> wrote:

I'd like to explain my rationale. Most of the time I end up using
"#[todo] Whatever" while documenting my code... my intentions are "#
[todo] ...", but you know... missing that space char doesn't break
anything today...

We could disagree on which is more common today @[] or #[], but I don't
have the numbers, so it's useless to argue that point (though I will say
that
@[$foo, $bar] = explode(...);
is valid syntax that does something while
#[todo] whatever
is just a comment and therefore a bit arbitrary.

But again, I'll agree to disagree on which of those two comes out less
problematic. Certainly in terms of YOUR vote, you can absolutely choose to
vote for something which doesn't break your workflow and that's 100%
valid. Certainly we can agree they have the same fundamental BC break
chance. And have the same work-around for fixing (add a space).

In any case, BC is broken and FC would also not work.

This is the part I replied to call out.
You seem to be stating that "FC would also not work" on the #[...] syntac
which is demonstrably false.

Writing this on PHP 7 (or any earlier version for that matter) would be
valid syntax (ignored as a comment):

#[SomeAttr(123)]
function someFunc() {}

That's what's meant by Forward Compatibility. Library/Framework authors
could aggressively adopt attributes with the #[...] syntax, they can NOT do
so with any other syntax.

-Sara

3 years ago by Andreas Leathley — view source

unread

Writing this on PHP 7 (or any earlier version for that matter) would be
valid syntax (ignored as a comment):

#[SomeAttr(123)]
function someFunc() {}

That's what's meant by Forward Compatibility. Library/Framework authors
could aggressively adopt attributes with the #[...] syntax, they can NOT do
so with any other syntax.

This would be a feature if libraries start parsing PHP token by token
and start supporting the #[] syntax for the 7.x versions of PHP - then
early adoption would be possible and it would be a real feature. But it
seems unclear if that will happen, as it will probably have a heavy
price on performance (and might have some complexity). And if some
libraries implement it but others don't, then it might get confusing for
users about why the new attribute syntax sometimes works and sometimes
silently does nothing.

It is also not perfect as multi-line attributes with #[ still break, or
code with #[] followed by more code instead of a newline and then more code.

3 years ago by Sara Golemon — view source

unread

On Tue, Aug 11, 2020 at 11:25 AM Andreas Leathley a.leathley@gmx.net
wrote:

This would be a feature if libraries start parsing PHP token by token
and start supporting the #[] syntax for the 7.x versions of PHP - then
early adoption would be possible and it would be a real feature. But it
seems unclear if that will happen, as it will probably have a heavy
price on performance (and might have some complexity). And if some
libraries implement it but others don't, then it might get confusing for
users about why the new attribute syntax sometimes works and sometimes
silently does nothing.

The perf penalty on 7 and earlier would probably be similar to existing
state of the world.
Parsing a docblock is easier to fetch from the runtime (as we actually
store it), but docblocks contain more than just annotations, so some plus
some minus.
PHP 8+ performance on theses would certainly be between though, and that's
an extra carrot to push users to upgrade. If annotations can't be written
until after users upgrade, then that carrot vanishes.

It is also not perfect as multi-line attributes with #[ still break, or
code with #[] followed by more code instead of a newline and then more
code.

That's true. It'll take some care (and possible reduction in readability)
to make annotations work well across verisons, but it's better to have an
option than not, no?
-Sara

3 years ago by Sara Golemon — view source

unread

PHP 8+ performance on theses would certainly be between though, and that's
an extra carrot to push users to upgrade. If annotations can't be written
until after users upgrade, then that carrot vanishes.

*PHP 8+ performance on these would certainly be better though.

Ugh... typing is hard.

-Sara

3 years ago by Andreas Leathley — view source

unread

The perf penalty on 7 and earlier would probably be similar to existing
state of the world.
Parsing a docblock is easier to fetch from the runtime (as we actually
store it), but docblocks contain more than just annotations, so some plus
some minus.
PHP 8+ performance on theses would certainly be between though, and that's
an extra carrot to push users to upgrade. If annotations can't be written
until after users upgrade, then that carrot vanishes.

If this is something that would realistically happen, I feel this would
have needed more explanation in an RFC and maybe some small tests to
demonstrate feasability, then it would be a big argument. I read through
all the RFCs, but only realized the meaning of this argument now, with
some more context. If the Doctrine Annotations library would support a
syntax with # for pre-PHP-8 and it would be fast enough, then this
argument would be more convincing to me than any of the others together.

And it would not need to be #[], it could be any syntax that starts with

- it could also be #@, which definitely seems weird at first, but

seems much less likely to occur in code than #[ and would be more
similar to current annotations and Javascript syntax. Or it could be
something completely different, like #~, which I cannot imagine ever
comes up in actual code. Because Rust using the #[] syntax does not seem
like an advantage, as Rust syntax in general looks completely different
compared to PHP.

3 years ago by Nikita Popov — view source

unread

Writing this on PHP 7 (or any earlier version for that matter) would be
valid syntax (ignored as a comment):

#[SomeAttr(123)]
function someFunc() {}

That's what's meant by Forward Compatibility. Library/Framework authors
could aggressively adopt attributes with the #[...] syntax, they can NOT
do
so with any other syntax.

This would be a feature if libraries start parsing PHP token by token
and start supporting the #[] syntax for the 7.x versions of PHP - then
early adoption would be possible and it would be a real feature. But it
seems unclear if that will happen, as it will probably have a heavy
price on performance (and might have some complexity). And if some
libraries implement it but others don't, then it might get confusing for
users about why the new attribute syntax sometimes works and sometimes
silently does nothing.

It is also not perfect as multi-line attributes with #[ still break, or
code with #[] followed by more code instead of a newline and then more
code.

To clarify the forward compatibility argument: As far as I understood, it's
not really about the end user, it's about the library implementing the
attribute. The library providing the Route attribute can write:

#[Attribute]
class Route
{
// ...
}

and make the Route attribute available both for use with PHP 8 attributes
and PHP 7 docblock annotations. With non-FC syntax choices this possibility
does not exist, and the library will be required to provide different class
hierarchies for docblock attributes and PHP 8 attributes.

The ability to write #[Route] for the user of that library is an additional
possibility on top of that, but one that is technically more involved. I
think the primary forward compatibility value lies in the above usage.

I believe this was explained in some of the earlier discussions, but I
wanted to repeat it in this thread, as there seems to be some confusion on
this point.

Regards,
Nikita

3 years ago by Paul M. Jones — view source

unread

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

Just chiming in to say all, y'all voting for @[...] are making a terrible
choice, and are you sure you're okay with it?

Maybe -- but we can always vote yet again on this, until the voters finally get it right.

--
Paul M. Jones
pmjones@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

3 years ago by Aleksander Machniak — view source

unread

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

Just chiming in to say all, y'all voting for @[...] are making a terrible
choice, and are you sure you're okay with it?

It looks like the community is split, and it might actually be a mistake
to implement the feature with any of the options on the table.

Maybe we should look for different approaches? Here's one. To not have
to use a new keyword I choose to try how "declare" would fit:

declare(
SomeAttr,
AntoherAttr("Hello world")
)
class someClass {
}

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

3 years ago by Theodore Brown — view source

unread

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The vote ends August 23, 24:00 UTC.

It has just come to my attention that this RFC was rushed to vote
after less than the minimum two week period required after it was
brought up on list. Furthermore, discussion was still very active at
that time - I certainly didn't have a chance to respond to some of
the emails before voting began.

Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the
vote was started this Monday at 3:41 AM, less than 12 days, 18 hours
after the announcement. Per the voting rules:

a minimum of 2 weeks between when an RFC that touches the language
is brought up on this list and when it's voted on is required. 1

What should be done to prevent this rule from being violated?

Also, I still don't understand why this RFC has a special exemption
to the feature freeze deadline, given that the whole basis for it
(a supposed lack of consistency) is at best a subjective opinion.

Can the RMs please weigh in?

Kind regards,
Theodore

3 years ago by Sara Golemon — view source

unread

On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown theodorejb@outlook.com
wrote:

It has just come to my attention that this RFC was rushed to vote
after less than the minimum two week period required after it was
brought up on list. Furthermore, discussion was still very active at
that time - I certainly didn't have a chance to respond to some of
the emails before voting began.

Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the
vote was started this Monday at 3:41 AM, less than 12 days, 18 hours
after the announcement. Per the voting rules:

So, 30 hours short of 2 weeks. I'm going to ascribe good intentions in
trying to get the issue resolved in the minimal timeframe. The fact active
discussion was ongoing makes this a questionable choice, but in my opinion,
purely on a matter of time, quibbling over 30 hours is splitting hairs.
Maybe compromise on adding time to the vote end period so that the total
is greater than 4 weeks?

What should be done to prevent this rule from being violated?

Vigilance. You're right to raise the concern. And let's wag a finger over
it at least. If others agree that it's premature, we can stop the vote,
but I'm not inclined to disrupt the process over such a small variance.

Also, I still don't understand why this RFC has a special exemption
to the feature freeze deadline, given that the whole basis for it
(a supposed lack of consistency) is at best a subjective opinion.

Changing the syntax isn't a feature. It's a refinement. One of the things
our long release process provides is a chance to be absolutely certain
before we introduce syntax we'll come to regret later.

-Sara

3 years ago by Paul M. Jones — view source

unread

If others agree that it's premature, we can stop the vote,
but I'm not inclined to disrupt the process over such a small variance.

It's premature. If we can't follow our own rules, why even have them?

--
Paul M. Jones
pmjones@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

3 years ago by Kalle Sommer Nielsen — view source

unread

Den ons. 12. aug. 2020 kl. 18.29 skrev Paul M. Jones pmjones@pmjones.io:

It's premature. If we can't follow our own rules, why even have them?

Agreed

--
regards,

Kalle Sommer Nielsen
kalle@php.net

3 years ago by Derick Rethans — view source

unread

Maybe compromise on adding time to the vote end period so that the
total is greater than 4 weeks?

You'd asked to get this done by beta3, which I miscalculated as being
tagged on August 25th. But as it's actually a week later I have no
problem extending it.

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

3 years ago by Andreas Leathley — view source

unread

Changing the syntax isn't a feature. It's a refinement. One of the things
our long release process provides is a chance to be absolutely certain
before we introduce syntax we'll come to regret later.

The current RFC does not discuss the BC breaks of each syntax (which
seems very important to any syntax changes), it has not taken into
account the discussion, and the RFC itself was being discussed for only
6 days (of which two days were on the weekend) before it started its
voting process. The discussion was still very much ongoing when voting
started.

Shoehorning in a syntax at the last minute seems like the opposite of a
controlled and long-term release process, at least if there is an
ongoing discussion. Looking at the RFC votes now, the opinions are
clearly split, which is not a good sign - at least in the previous RFC
@@ was a clear winner. Changing syntax again now for the third time
could just as well be the decision that will be regretted later on,
instead of finding a better concensus in due time.

3 years ago by Theodore Brown — view source

unread

It has just come to my attention that this RFC was rushed to vote
after less than the minimum two week period required after it was
brought up on list. Furthermore, discussion was still very active at
that time - I certainly didn't have a chance to respond to some of
the emails before voting began.

Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the
vote was started this Monday at 3:41 AM, less than 12 days, 18 hours
after the announcement. Per the voting rules:

So, 30 hours short of 2 weeks. I'm going to ascribe good intentions
in trying to get the issue resolved in the minimal timeframe. The
fact active discussion was ongoing makes this a questionable choice,
but in my opinion, purely on a matter of time, quibbling over 30 hours
is splitting hairs. Maybe compromise on adding time to the vote end
period so that the total is greater than 4 weeks?

What should be done to prevent this rule from being violated?

Vigilance. You're right to raise the concern. And let's wag a finger
over it at least. If others agree that it's premature, we can stop
the vote, but I'm not inclined to disrupt the process over such a
small variance.

On top of violating the minimum two week discussion period, I believe
this RFC also breaks the rule on resurrecting failed proposals. When
I authored the Shorter Attribute Syntax RFC, I specifically did not
include a voting option for @:, since this syntax was declined,
and my understanding was that a six month waiting period is required
before resurrecting rejected proposals. 1

But if we can vote again on #[] and <<>> after they were declined,
why can't we also vote again for @:? This syntax has the advantage
of being equally short as @@ without any BC break.

I'm really disappointed and disillusioned with how the process has
been handled for this RFC. It seems like the rules are arbitrarily
going out the window in order to keep voting until the desired result
is reached.

What is the point of having rules if they aren't followed or enforced?
If anyone else is troubled by the precedent being set by this RFC,
please vote No on the primary vote. I'm not sure what other recourse
we have at this point.

Sincerely,
Theodore

3 years ago by michal.brzuchalski@gmail.com — view source

unread

Hi Theodore,

śr., 12 sie 2020 o 18:36 Theodore Brown theodorejb@outlook.com napisał(a):

It has just come to my attention that this RFC was rushed to vote
after less than the minimum two week period required after it was
brought up on list. Furthermore, discussion was still very active at
that time - I certainly didn't have a chance to respond to some of
the emails before voting began.

Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the
vote was started this Monday at 3:41 AM, less than 12 days, 18 hours
after the announcement. Per the voting rules:

So, 30 hours short of 2 weeks. I'm going to ascribe good intentions
in trying to get the issue resolved in the minimal timeframe. The
fact active discussion was ongoing makes this a questionable choice,
but in my opinion, purely on a matter of time, quibbling over 30 hours
is splitting hairs. Maybe compromise on adding time to the vote end
period so that the total is greater than 4 weeks?

What should be done to prevent this rule from being violated?

Vigilance. You're right to raise the concern. And let's wag a finger
over it at least. If others agree that it's premature, we can stop
the vote, but I'm not inclined to disrupt the process over such a
small variance.

On top of violating the minimum two week discussion period, I believe
this RFC also breaks the rule on resurrecting failed proposals. When
I authored the Shorter Attribute Syntax RFC, I specifically did not
include a voting option for @:, since this syntax was declined,
and my understanding was that a six month waiting period is required
before resurrecting rejected proposals. 1

But if we can vote again on #[] and <<>> after they were declined,
why can't we also vote again for @:? This syntax has the advantage
of being equally short as @@ without any BC break.

I'm really disappointed and disillusioned with how the process has
been handled for this RFC. It seems like the rules are arbitrarily
going out the window in order to keep voting until the desired result
is reached.

What is the point of having rules if they aren't followed or enforced?
If anyone else is troubled by the precedent being set by this RFC,
please vote No on the primary vote. I'm not sure what other recourse
we have at this point.

Sincerely,
Theodore

You hint to the fact of shorter discussion period and the fact
that you haven't got time to respond to all discussions while if you take a
closer look
on ML 4 that is obvious that discussion in fact began earlier and it's 3
weeks from now
and to avoid insinuation you replied to it 5 3 weeks ago as well.

You blame others for breaking rules which in fact are not broken.
IMO you think they're broken cause of your own interpretation.
Rejected features have nothing to do with a re-vote on a syntax change
at least this is how I understand this.
Besides you already mentioned this argument on ML 1 so we can argue
actually if
a re-vote on syntax change is actually resurrecting a declined proposal
since
it was not a standalone proposal which got into a declined section of RFC's
index 2
and yet you did it again!

You blame others for "abusing" the RFC process while you've brought to us
an RFC
with a significant ambiguity 3 which you haven't mention and it turned
out after closing a vote.
Personally I think that it was your huge failure to bring the previous @@
syntax change
RFC up to the voting without checking it's correctness.

I'm personally also disappointed with the fact that in your RFC under the
primary
vote question "Are you okay with re-voting on the attribute syntax for PHP
8.0?"
removing features like grouping ability was hidden.

Personally I think you're forcing to stop the re-vote cause of mental
connection to your previous @@ RFC and trying hard to find an argument
against the re-vote.
From the results which are available so far, it can be seen
that your proposed syntax is no longer the leading one.
I understand it fully cause I'd be upset as well.

From my own experience, I know that as a RFC author there has always be
a place to just let it go
cause you won't always get to convince 50+ voters to your PoV.

Cheers,
Michał Marcin Brzuchalski

3 years ago by come.chilliet@fusiondirectory.org — view source

unread

Le Thu, 13 Aug 2020 10:13:16 +0200,
Michał Marcin Brzuchalski michal.brzuchalski@gmail.com a écrit :

I'm personally also disappointed with the fact that in your RFC under the
primary
vote question "Are you okay with re-voting on the attribute syntax for PHP
8.0?"
removing features like grouping ability was hidden.

I still do not understand this point on grouping, how is using a syntax like @@
or any that does not require grouping removing anything?

What is the grouping feature supposed to do?

3 years ago by Theodore Brown — view source

unread

Hi Theodore,

śr., 12 sie 2020 o 18:36 Theodore Brown theodorejb@outlook.com napisał(a):

It has just come to my attention that this RFC was rushed to vote
after less than the minimum two week period required after it was
brought up on list. Furthermore, discussion was still very active at
that time - I certainly didn't have a chance to respond to some of
the emails before voting began.

Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and the
vote was started this Monday at 3:41 AM, less than 12 days, 18 hours
after the announcement. Per the voting rules:

So, 30 hours short of 2 weeks. I'm going to ascribe good intentions
in trying to get the issue resolved in the minimal timeframe. The
fact active discussion was ongoing makes this a questionable choice,
but in my opinion, purely on a matter of time, quibbling over 30 hours
is splitting hairs. Maybe compromise on adding time to the vote end
period so that the total is greater than 4 weeks?

What should be done to prevent this rule from being violated?

Vigilance. You're right to raise the concern. And let's wag a finger
over it at least. If others agree that it's premature, we can stop
the vote, but I'm not inclined to disrupt the process over such a
small variance.

On top of violating the minimum two week discussion period, I believe
this RFC also breaks the rule on resurrecting failed proposals. When
I authored the Shorter Attribute Syntax RFC, I specifically did not
include a voting option for @:, since this syntax was declined,
and my understanding was that a six month waiting period is required
before resurrecting rejected proposals. 1

But if we can vote again on #[] and <<>> after they were declined,
why can't we also vote again for @:? This syntax has the advantage
of being equally short as @@ without any BC break.

I'm really disappointed and disillusioned with how the process has
been handled for this RFC. It seems like the rules are arbitrarily
going out the window in order to keep voting until the desired result
is reached.

What is the point of having rules if they aren't followed or enforced?
If anyone else is troubled by the precedent being set by this RFC,
please vote No on the primary vote. I'm not sure what other recourse
we have at this point.

Sincerely,
Theodore

You hint to the fact of shorter discussion period and the fact that
you haven't got time to respond to all discussions while if you take
a closer look on ML 4 that is obvious that discussion in fact began
earlier and it's 3 weeks from now and to avoid insinuation you replied
to it 5 3 weeks ago as well.

Hi Michał,

The discussion thread you're referencing did not announce an RFC. Per
the voting rules, a "Proposal is formally initiated by creating an
RFC on PHP wiki and announcing it on the list". After that there must
be a minimum two week discussion period before voting starts. The
Shorter Attribute Syntax Change RFC failed to meet this requirement.

Rejected features have nothing to do with a re-vote on a syntax
change at least this is how I understand this. Besides you already
mentioned this argument on ML 1 so we can argue actually if a
re-vote on syntax change is actually resurrecting a declined
proposal since it was not a standalone proposal which got into a
declined section of RFC's index 2 and yet you did it again!

So you're saying that the rule on resurrecting failed proposals only
applies to primary votes, and not secondary votes? So if a secondary
vote fails it's okay to vote for it again and again until the desired
result it reached? This is not my understanding of the rules.

You blame others for "abusing" the RFC process while you've brought
to us an RFC with a significant ambiguity 3 which you haven't
mention and it turned out after closing a vote. Personally I think
that it was your huge failure to bring the previous @@ syntax change
RFC up to the voting without checking it's correctness.

It was correct as far as we knew at the time. Anyway, this issue was
fixed before the @@ syntax was merged, and I don't see its relevance
to this discussion.

I'm personally also disappointed with the fact that in your RFC under
the primary vote question "Are you okay with re-voting on the
attribute syntax for PHP 8.0?" removing features like grouping
ability was hidden.

I don't follow you. The grouping feature for <<>> wasn't even accepted
yet when the Shorter Attribute Syntax RFC went to vote. One of the
primary motivations of the Shorter Attribute Syntax RFC was to reduce
verbosity and remove the need for two different syntaxes (grouped and
non-grouped) for declaring attributes. It was also discussed on list
how @@ is equally or more concise without grouping:
https://externals.io/message/110355#110414. Finally, the Attribute
Amendments RFC itself explicitly stated that the grouped attribute
feature "would be superseded by any other RFC getting accepted that
changes the syntax."

Attribute grouping makes some sense to help reduce the verbosity of
the @[], #[], and especially <<>> syntaxes, but with @@ there is no
need for the extra complexity since it is equally concise without it.

Personally I think you're forcing to stop the re-vote cause of mental
connection to your previous @@ RFC and trying hard to find an argument
against the re-vote. From the results which are available so far, it
can be seen that your proposed syntax is no longer the leading one.
I understand it fully cause I'd be upset as well.

If it was just a matter of my personal syntax preference I wouldn't
be having this discussion. I was fine with voting on #[] originally
and included it as an option in the Shorter Attribute Syntax RFC.

What I have a serious problem with is breaking rules to arbitrarily
vote again in the hopes that this time voters will choose #[] even
though it was declined in the last vote. Moreover, the current RFC
does not fairly present all the pros and cons of each syntax, and
the requests of myself and others to include additional important
details in the RFC about the BC breaks and other considerations have
not been heeded.

What is happening here is wrong, and because I want the best for PHP
I have to stand up to it.

Sincerely,
Theodore

3 years ago by michal.brzuchalski@gmail.com — view source

unread

Hi Theodore,

czw., 13 sie 2020 o 15:17 Theodore Brown theodorejb@outlook.com
napisał(a):

On Thu, Aug 13, 2020 at 3:13 AM Michał Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

Hi Theodore,

śr., 12 sie 2020 o 18:36 Theodore Brown theodorejb@outlook.com
napisał(a):

It has just come to my attention that this RFC was rushed to vote
after less than the minimum two week period required after it was
brought up on list. Furthermore, discussion was still very active
at
that time - I certainly didn't have a chance to respond to some of
the emails before voting began.

Joe first announced this RFC on Tuesday, July 28 at 9:47 AM, and
the
vote was started this Monday at 3:41 AM, less than 12 days, 18
hours
after the announcement. Per the voting rules:

So, 30 hours short of 2 weeks. I'm going to ascribe good intentions
in trying to get the issue resolved in the minimal timeframe. The
fact active discussion was ongoing makes this a questionable choice,
but in my opinion, purely on a matter of time, quibbling over 30
hours
is splitting hairs. Maybe compromise on adding time to the vote end
period so that the total is greater than 4 weeks?

What should be done to prevent this rule from being violated?

Vigilance. You're right to raise the concern. And let's wag a finger
over it at least. If others agree that it's premature, we can stop
the vote, but I'm not inclined to disrupt the process over such a
small variance.

On top of violating the minimum two week discussion period, I believe
this RFC also breaks the rule on resurrecting failed proposals. When
I authored the Shorter Attribute Syntax RFC, I specifically did not
include a voting option for @:, since this syntax was declined,
and my understanding was that a six month waiting period is required
before resurrecting rejected proposals. 1

But if we can vote again on #[] and <<>> after they were declined,
why can't we also vote again for @:? This syntax has the advantage
of being equally short as @@ without any BC break.

I'm really disappointed and disillusioned with how the process has
been handled for this RFC. It seems like the rules are arbitrarily
going out the window in order to keep voting until the desired result
is reached.

What is the point of having rules if they aren't followed or enforced?
If anyone else is troubled by the precedent being set by this RFC,
please vote No on the primary vote. I'm not sure what other recourse
we have at this point.

Sincerely,
Theodore

You hint to the fact of shorter discussion period and the fact that
you haven't got time to respond to all discussions while if you take
a closer look on ML 4 that is obvious that discussion in fact began
earlier and it's 3 weeks from now and to avoid insinuation you replied
to it 5 3 weeks ago as well.

Hi Michał,

The discussion thread you're referencing did not announce an RFC. Per
the voting rules, a "Proposal is formally initiated by creating an
RFC on PHP wiki and announcing it on the list". After that there must
be a minimum two week discussion period before voting starts. The
Shorter Attribute Syntax Change RFC failed to meet this requirement.

True, but you cannot disagree that you knew about the discussion coming soon
and yet it was 3 weeks ago.
True that the announcement was delayed but TBH for me, discussion began
earlier
and we argue about that while more than 43 votes who voted yes in the
primary vote
had no hard feelings about it.

Rejected features have nothing to do with a re-vote on a syntax
change at least this is how I understand this. Besides you already
mentioned this argument on ML 1 so we can argue actually if a
re-vote on syntax change is actually resurrecting a declined
proposal since it was not a standalone proposal which got into a
declined section of RFC's index 2 and yet you did it again!

So you're saying that the rule on resurrecting failed proposals only
applies to primary votes, and not secondary votes? So if a secondary
vote fails it's okay to vote for it again and again until the desired
result it reached? This is not my understanding of the rules.

Agree. This is how I understand this and this is my personal opinion on
that.

You blame others for "abusing" the RFC process while you've brought

to us an RFC with a significant ambiguity 3 which you haven't
mention and it turned out after closing a vote. Personally I think
that it was your huge failure to bring the previous @@ syntax change
RFC up to the voting without checking it's correctness.

It was correct as far as we knew at the time. Anyway, this issue was
fixed before the @@ syntax was merged, and I don't see its relevance
to this discussion.

I do not hint to the fact that the issue was accidentally fixed due to
another planned RFC.
The thing I do hint about here is the fact that the RFC even got into
voting with an
ambiguity issue and that's a failure of RFC's author.

This proves RFC authors make mistakes all the time and since this vote
being
in the vote for couple of days have so much yes votes on primary poll proves
that mistakes to some degree might be forgiven.

In case of your mistake AFAIK nobody asked you to withdraw accepted RFC
after
a mistake made by you was found, right?

I'm personally also disappointed with the fact that in your RFC under

the primary vote question "Are you okay with re-voting on the
attribute syntax for PHP 8.0?" removing features like grouping
ability was hidden.

I don't follow you. The grouping feature for <<>> wasn't even accepted
yet when the Shorter Attribute Syntax RFC went to vote. One of the
primary motivations of the Shorter Attribute Syntax RFC was to reduce
verbosity and remove the need for two different syntaxes (grouped and
non-grouped) for declaring attributes. It was also discussed on list
how @@ is equally or more concise without grouping:
https://externals.io/message/110355#110414. Finally, the Attribute
Amendments RFC itself explicitly stated that the grouped attribute
feature "would be superseded by any other RFC getting accepted that
changes the syntax."

Attribute grouping makes some sense to help reduce the verbosity of
the @[], #[], and especially <<>> syntaxes, but with @@ there is no
need for the extra complexity since it is equally concise without it.

Personally I think you're forcing to stop the re-vote cause of mental
connection to your previous @@ RFC and trying hard to find an argument
against the re-vote. From the results which are available so far, it
can be seen that your proposed syntax is no longer the leading one.
I understand it fully cause I'd be upset as well.

If it was just a matter of my personal syntax preference I wouldn't
be having this discussion. I was fine with voting on #[] originally
and included it as an option in the Shorter Attribute Syntax RFC.

What I have a serious problem with is breaking rules to arbitrarily
vote again in the hopes that this time voters will choose #[] even
though it was declined in the last vote. Moreover, the current RFC
does not fairly present all the pros and cons of each syntax, and
the requests of myself and others to include additional important
details in the RFC about the BC breaks and other considerations have
not been heeded.

What is happening here is wrong, and because I want the best for PHP
I have to stand up to it.

Here we agree. I also do want the best for PHP!

Cheers,
Michał Marcin Brzuchalski

3 years ago by Andreas Leathley — view source

unread

The discussion thread you're referencing did not announce an RFC. Per
the voting rules, a "Proposal is formally initiated by creating an
RFC on PHP wiki and announcing it on the list". After that there must
be a minimum two week discussion period before voting starts. The
Shorter Attribute Syntax Change RFC failed to meet this requirement.

After reading https://wiki.php.net/rfc/howto it is stated clearly there
that an RFC has to be created and be "Under Discussion" for at least two
weeks. So you were actually wrong that the RFC was one day early - it
was at least 8 days early, as the RFC was created and announced on the
4th of August and then put to vote on the 10th of August.

It also states in this document:

Listen to the feedback, and try to answer/resolve all questions
Update your RFC to document all the issues and discussions
Cover both the positive and negative arguments

Can anybody say with a straight face that this has been done in this
case? Just one example: It still states in the RFC that the ending
symbol is inconsistent with the language, although multiple people
argued another viewpoint about this part with detailed explanations.
This kind of discussion belongs in an RFC to show both sides, not just
the one that suits the person writing the RFC.

3 years ago by Theodore Brown — view source

unread

The discussion thread you're referencing did not announce an RFC. Per
the voting rules, a "Proposal is formally initiated by creating an
RFC on PHP wiki and announcing it on the list". After that there must
be a minimum two week discussion period before voting starts. The
Shorter Attribute Syntax Change RFC failed to meet this requirement.

After reading https://wiki.php.net/rfc/howto it is stated clearly there
that an RFC has to be created and be "Under Discussion" for at least two
weeks. So you were actually wrong that the RFC was one day early - it
was at least 8 days early, as the RFC was created and announced on the
4th of August and then put to vote on the 10th of August.

Indeed, it looks like you are right. I missed that Joe withdrew his
RFC on August 2nd: https://externals.io/message/111218#111288. The
declined RFC can still be viewed via a past page revision. 1

Apparently Derick then authored a new proposal under the same wiki
URL and moved it under discussion on August 4th, with a request that
people submit patches for other syntax alternatives to include in the
vote. 2 So the first date this RFC could be eligible for voting is
Tuesday August 18th.

Sara and Gabriel, can you confirm this is the case?

The RFC was then moved to voting on August 10th, less than a week
later, before there was a reasonable period to submit patches, and
while there was still significant ongoing and unresolved discussion.

It also states in this document:

Listen to the feedback, and try to answer/resolve all questions

Update your RFC to document all the issues and discussions

Cover both the positive and negative arguments

Can anybody say with a straight face that this has been done in this
case? Just one example: It still states in the RFC that the ending
symbol is inconsistent with the language, although multiple people
argued another viewpoint about this part with detailed explanations.
This kind of discussion belongs in an RFC to show both sides, not
just the one that suits the person writing the RFC.

Hear, hear. If we must vote again on the syntax, can the RFC at least
fairly present all the pros and cons for each alternative (including
details about the BC breaks), with a discussion section summarizing
the viewpoints brought up on list? This is what I attempted to do in
the original Shorter Attribute Syntax RFC. 3

Best regards,
Theodore

3 years ago by Paul M. Jones — view source

unread

Indeed, it looks like you are right. I missed that Joe withdrew his
RFC on August 2nd: https://externals.io/message/111218#111288. The
declined RFC can still be viewed via a past page revision. [1]

Apparently Derick then authored a new proposal under the same wiki
URL and moved it under discussion on August 4th, with a request that
people submit patches for other syntax alternatives to include in the
vote. [2] So the first date this RFC could be eligible for voting is
Tuesday August 18th.

So, a week+ early, then? Surely that means the current vote null and void, to be reset entirely following a proper discussion period -- one without concurrent voting.

--
Paul M. Jones
pmjones@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

3 years ago by Levi Morrison via internals — view source

unread

So, a week+ early, then? Surely that means the current vote null and void, to be reset entirely following a proper discussion period -- one without concurrent voting.

I just want to make sure I understand: there are people who think we
haven't discussed the syntax for attributes yet?

I assume this is a serious email, but I can't fathom why anyone cares.
We've discussed this subject soo much...

3 years ago by Andreas Leathley — view source

unread

I just want to make sure I understand: there are people who think we
haven't discussed the syntax for attributes yet?

I assume this is a serious email, but I can't fathom why anyone cares.
We've discussed this subject soo much...

I am kind of new to the Internals discussions, which might be the reason
why I actually read through all the RFC process material, but I
recommend anyone to do so too. I will highlight the relevant parts as
succinctly as possible:

In https://wiki.php.net/rfc/howto - How to create an RFC - it says:

When your RFC is ready for discussion, change the status of your RFC
page to "Under Discussion", and send an mail to
internals@lists.php.net introducing your RFC.
Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the issues and discussions. Cover
both the positive and negative arguments. Put the RFC URL into all
your replies.
When discussion ends, and a minimum period of two weeks has passed
since you mailed internals@lists.php.net in step 4, consider one day
heads up mail on the mailing list and then you can move your RFC to
“Voting” status. There should be no open questions in the RFC.

The two weeks discussion period is specifically about the RFC itself,
not the discussion at large, which does make sense to me, as you discuss
a specific proposal and are trying to include all relevant information
into that RFC, so people voting on the RFC do not have to read through
all emails in Internals to get the information - it should be on the RFC
page. This is something objectively lacking with this RFC.

In https://wiki.php.net/RFC/voting - Voting on PHP features - it says:

Proposal is formally initiated by creating an RFC on PHP wiki and
announcing it on the list.
There'd be a minimum of 2 weeks between when an RFC that touches the
language is brought up on this list and when it's voted on is
required. Other RFCs might use a smaller timeframe, but it should be
at least a week. The effective date will not be when the RFC was
published on the PHP wiki - but when it was announced on
internals@lists.php.net, by the author, with the intention of voting
on it. This period can be extended when circumstances warrant it -
such as major conferences, key people being busy, force major
events, or when discussion merits it - but should never be less than
minimal time.
This does not preclude discussion on the merits on any idea or
proposal on the list without formally submitting it as a proposal,
but the discussion time is measured only since the formal discussion
announcement as described above.

Here it also specifically mentions a discussion period of two weeks
after the RFC was created and announced on the list, yet it mentions it
can be only one week if it "does not touch the language". An RFC with a
syntax change would definitely touch the language in my opinion.

It also mentions again that the discussion period is after the
announcement on the list of the RFC - not after the discussion began
about the topic in general. The RFC has to exist and be mentioned with
the intent on voting on it.

Now, I don't know all the history of past RFCs, and maybe some of these
rules were not always followed, which someone alluded to in another
email. Yet in my understanding of the process, if nobody mentions that
timeframes were not heeded or that RFCs are incomplete, it seems likely
that there is already a large concensus around the topic, and nobody
cares about the details of the process. This is fine, and no harm is
done, although it might be good to remember the rules just to be consistent.

If on the other hand people reference the documents that should steer
the RFC process and there is a clear violation of those, and if there
are multiple people who feel their points have not been included in an
RFC, then it makes sense to actually read through the RFC documents
again and follow them as intended, as obviously the intent of these
documents are different from what is happening.

Something else to point out, on https://wiki.php.net/rfc at the top it says:

An RFC is effectively “owned” by the person that created it. If you
want to make changes, get permission from the creator. If no
agreement can be found, the only course of action is to create a
competing RFC. In this case, the old RFC page should be modified to
become an intermediate page that points to all the competing RFC's.

This might be an alternative, if the many discussion points are not
included in this RFC and it therefore remains incomplete, to make a
competing RFC. Not sure if this has ever been done, but it is on the
main RFC overview page, although it seems sad if that would be necessary.

I would like to mention that I would help any efforts to make this or
another RFC about a possible attribute syntax change as
information-complete as possible. For me this is not about the syntax,
but about properly thinking about the syntax (and discussing all
ramifications) and gathering as much information about each syntax and
its possible pros/cons/outcomes as possible. Many emails in Internals
have changed my mind in one way or the other, so that kind of
information not being included in the RFC will lead to people basing
their decisions on incomplete information, which seems bad to me.

3 years ago by Theodore Brown — view source

unread

So, a week+ early, then? Surely that means the current vote null
and void, to be reset entirely following a proper discussion period
-- one without concurrent voting.

I just want to make sure I understand: there are people who think we
haven't discussed the syntax for attributes yet?

I assume this is a serious email, but I can't fathom why anyone cares.
We've discussed this subject soo much...

Hi Levi and internals,

There's certainly been a lot of discussion in general about
attributes. However, there was not a reasonable opportunity to either
discuss the specific arguments made in this RFC (e.g. the lack of a
closing symbol being inconsistent), or submit patches for alternative
syntaxes as Derick requested when he put up the RFC for discussion.

I was very surprised that it went to vote less than six days after
the discussion period started, right after the weekend no less,
before I had a chance to submit my patch to include the @: syntax.

I'm as weary of the discussion as anyone, and would like to see
closure on this topic sooner rather than later. But if the voting
rules aren't followed, how can the vote result be considered
legitimate or binding?

If the authors sincerely want the best outcome for the language (and
I assume they do), what harm is there in deferring the vote until the
discussion period has completed, and ensuring that the RFC addresses
the arguments on both sides and contains all the relevant information
for making a decision? Otherwise many contributors (myself included)
just end up feeling unheard, unhappy, and unconfident that the right
choice is being made.

With this in mind, I'd like to respectfully make the following
requests:

Defer voting until the two week discussion period is complete
(Tuesday, August 18).
Include a ranked voting option for @: and mention its pros and
cons (it is equally concise as @@ with no BC break, but is somewhat
harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1
Add a Backward Incompatible Changes section with examples of the
code that the different syntax options would break.
Add a Discussion section briefly summarizing the arguments that
have come up on list. In particular this should include:
a) Tyson's examples of #[] changing the meaning of code in
unexpected ways between PHP 7 and 8 (e.g. a parameter
attribute would remove the parameter when run on PHP 7).
b) An example of the downside of grouping, where it causes
unnecessary diff noise when adding or removing a second
attribute on its own line.
I'd be willing to help draft this section if the RFC authors so desire.

Derick and Benjamin (and Sara), are these requests reasonable? If the
RFC follows the discussion period rule and contains all the relevant
information, I will be much more confident that it is resulting in
the best long term outcome (and I think this would speak for many
others on list as well).

Sincerely,
Theodore

3 years ago by Benjamin Eberlei — view source

unread

On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown theodorejb@outlook.com
wrote:

On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison levi.morrison@datadoghq.com
wrote:

So, a week+ early, then? Surely that means the current vote null
and void, to be reset entirely following a proper discussion period
-- one without concurrent voting.

I just want to make sure I understand: there are people who think we
haven't discussed the syntax for attributes yet?

I assume this is a serious email, but I can't fathom why anyone cares.
We've discussed this subject soo much...

Hi Levi and internals,

There's certainly been a lot of discussion in general about
attributes. However, there was not a reasonable opportunity to either
discuss the specific arguments made in this RFC (e.g. the lack of a
closing symbol being inconsistent), or submit patches for alternative
syntaxes as Derick requested when he put up the RFC for discussion.

I was very surprised that it went to vote less than six days after
the discussion period started, right after the weekend no less,
before I had a chance to submit my patch to include the @: syntax.

I'm as weary of the discussion as anyone, and would like to see
closure on this topic sooner rather than later. But if the voting
rules aren't followed, how can the vote result be considered
legitimate or binding?

If the authors sincerely want the best outcome for the language (and
I assume they do), what harm is there in deferring the vote until the
discussion period has completed, and ensuring that the RFC addresses
the arguments on both sides and contains all the relevant information
for making a decision? Otherwise many contributors (myself included)
just end up feeling unheard, unhappy, and unconfident that the right
choice is being made.

With this in mind, I'd like to respectfully make the following
requests:

Defer voting until the two week discussion period is complete
(Tuesday, August 18).

What do you mean by defer exactly? Stop voting or reset the vote? We were
thinking of extending the vote until September 1st.

Include a ranked voting option for @: and mention its pros and
cons (it is equally concise as @@ with no BC break, but is somewhat
harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1

I am wondering where @: is suddenly coming from? It wasn't discussed in
both shorter attributes RFC and the discussion leading to this RFC.

There were a few other suggestions like $() or "using attribute", but none
of them was followed up upon. Nobody replied to my or Dericks message with
a specific interest in actually contributing another patch, including @:

Add a Backward Incompatible Changes section with examples of the
code that the different syntax options would break.

Derick and I are working on this section to update the RFC later today. We
didn't consider this relevant, because the mitigation steps for all of them
is the same: a project wide search and replace to insert a space

Code search across open-source showed that the number of occurrences vary,
but are all extremely low.

In addition all BC breaks are clean cut and lead to a fatal error that is
unlikely to go undetected when upgrading to PHP 8 (specifically in contrast
to the number conversion RFCs BC breaks).

Add a Discussion section briefly summarizing the arguments that
have come up on list. In particular this should include:
a) Tyson's examples of #[] changing the meaning of code in
unexpected ways between PHP 7 and 8 (e.g. a parameter
attribute would remove the parameter when run on PHP 7).

This is also included in the update, but ultimately is covered by the
explanation for "Forward Compatibility" already mentioning that it does
only work with a subset (and hence does not work for some other subset).

b) An example of the downside of grouping, where it causes

   unnecessary diff noise when adding or removing a second
   attribute on its own line.

This is a problem for coding styles to solve and is nothing the RFC should
be concerned with. Grouped syntax specifically includes support trailing
commas. Diff noise is something all declarations
with optional elements can cause, even use of @@ in one line can be
"forced" from single to multi lines creating diff noise under reasonable
Coding Standard assumptions.
As such I don't want to add coding style considerations at all, because
everyone is free to make them on their own anyways.

I'd be willing to help draft this section if the RFC authors so desire.

Derick and Benjamin (and Sara), are these requests reasonable? If the
RFC follows the discussion period rule and contains all the relevant
information, I will be much more confident that it is resulting in
the best long term outcome (and I think this would speak for many
others on list as well).

Sincerely,
Theodore

3 years ago by Paul M. Jones — view source

unread

What do you mean by defer exactly? Stop voting or reset the vote? We were
thinking of extending the vote until September 1st.

For my part, "extending a vote that started too early to let it run longer" is not a reasonable remedy. The right thing to do here is not to try to salvage the time spent and thereby depart even further from normal conduct, but instead to stop the vote, declare it null and void, and restart a proper two-week pre-vote discussion period.

(That presumes the need for the RFC even exists, which I submit it does not -- but that's a separate topic.)

--
Paul M. Jones
pmjones@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

3 years ago by Joe Ferguson — view source

unread

(That presumes the need for the RFC even exists, which I submit it does not -- but that's a separate topic.)

The most frustrating part of this entire bike shed and devolution into
finger pointing of rule breaking could have all been avoided if
Internals had a proper governing body which was capable of empowering
release managers to make a decision that the 2nd runner up of the Short
Attribute Syntax RFC should have been used when the original
implementation raised several questions after the vote.

Internals needs governance and the ability to empower decision makers.
And a code of conduct (The Python CoC is quite fantastic), but I
digress, as to not cause too many simultaneous aneurysms.

"The bike shedding will continue until morale improves"

Joe Ferguson

3 years ago by Theodore Brown — view source

unread

There's certainly been a lot of discussion in general about
attributes. However, there was not a reasonable opportunity to either
discuss the specific arguments made in this RFC (e.g. the lack of a
closing symbol being inconsistent), or submit patches for alternative
syntaxes as Derick requested when he put up the RFC for discussion.

I was very surprised that it went to vote less than six days after
the discussion period started, right after the weekend no less,
before I had a chance to submit my patch to include the @: syntax.

I'm as weary of the discussion as anyone, and would like to see
closure on this topic sooner rather than later. But if the voting
rules aren't followed, how can the vote result be considered
legitimate or binding?

If the authors sincerely want the best outcome for the language (and
I assume they do), what harm is there in deferring the vote until the
discussion period has completed, and ensuring that the RFC addresses
the arguments on both sides and contains all the relevant information
for making a decision? Otherwise many contributors (myself included)
just end up feeling unheard, unhappy, and unconfident that the right
choice is being made.

With this in mind, I'd like to respectfully make the following
requests:

Defer voting until the two week discussion period is complete
(Tuesday, August 18).

What do you mean by defer exactly? Stop voting or reset the vote?
We were thinking of extending the vote until September 1st.

Hi Benjamin,

Yes, my request is to stop/reset the vote until after the discussion
period is complete. Otherwise few people will see the updates made to
the RFC since they already voted.

Include a ranked voting option for @: and mention its pros and
cons (it is equally concise as @@ with no BC break, but is somewhat
harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1

I am wondering where @: is suddenly coming from? It wasn't discussed
in both shorter attributes RFC and the discussion leading to this RFC.

@: wasn't included in the Shorter Attribute Syntax RFC because I
didn't realize it was allowed to re-vote on a failed secondary poll
after less than six months. However, since we're re-voting on #[] I
think it's only fair to include @: as well - some people may prefer a
short syntax but dislike the specific look of @@. Personally I would
like to vote for @@ as my first preference and @: as my second.

There were a few other suggestions like $() or "using attribute", but
none of them was followed up upon. Nobody replied to my or Dericks
message with a specific interest in actually contributing another patch,
including @:

I hadn't replied to this part of Derick's message yet because the
voting started before I had a chance to write the patch.

Add a Backward Incompatible Changes section with examples of the
code that the different syntax options would break.

Derick and I are working on this section to update the RFC later today.
We didn't consider this relevant, because the mitigation steps for all
of them is the same: a project wide search and replace to insert a space

Thank you for working on this. The mitigation for current usages of
@@ should be to delete the extra symbol rather than adding a space
(though I'm very doubtful that any usages of @@ even exist currently,
since extra suppression operators don't do anything useful).

The main benefit of the BC break section will be to highlight examples
of how @[] and #[] break syntax that is both valid and useful, while
@@ does not.

Add a Discussion section briefly summarizing the arguments that
have come up on list. In particular this should include:
a) Tyson's examples of #[] changing the meaning of code in
unexpected ways between PHP 7 and 8 (e.g. a parameter
attribute would remove the parameter when run on PHP 7).

This is also included in the update, but ultimately is covered by the
explanation for "Forward Compatibility" already mentioning that it
does only work with a subset (and hence does not work for some other
subset).

Okay, but I think examples are necessarily to illustrate which subset
of the new syntax works and what does not. It certainly wasn't clear
to me before I saw Tyson's examples.

b) An example of the downside of grouping, where it causes
unnecessary diff noise when adding or removing a second
attribute on its own line.

This is a problem for coding styles to solve and is nothing the RFC
should be concerned with. Grouped syntax specifically includes support
[for] trailing commas. Diff noise is something all declarations with
optional elements can cause, even use of @@ in one line can be "forced"
from single to multi lines creating diff noise under reasonable Coding
Standard assumptions.

Even if you "force" an attribute with @@ across multiple lines, that
individual attribute can still be added/removed without modifying the
attributes on other lines.

On the other hand, with grouping the only way to avoid modifying
extra lines when adding/removing a second attribute would be to
mandate that the first attribute always be written like this:

#[
    SomeAttribute,
]
function foo() {}

But this also makes diffs noisier since at the very start two extra
lines have to be included.

Best regards,
Theodore

3 years ago by Sara Golemon — view source

unread

On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown theodorejb@outlook.com
wrote:

I was very surprised that it went to vote less than six days after
the discussion period started, right after the weekend no less,
before I had a chance to submit my patch to include the @: syntax.

Yes. Derick fucked up the letter of the rule here.
His intentions were good and reasonable (God knows we've discussed this
agonizing topic for far longer than two weeks), but taking the RFC in
question in a vacuum, it is well under two weeks.
By the intent of the rule, he's fine. This has been discussed
exhaustively.

How can the vote result be considered legitimate or binding?

Exhaustingly, I do agree. Contentious times call for careful outcomes.

If the authors sincerely want the best outcome for the language (and
I assume they do), what harm is there in deferring the vote until the
discussion period has completed, and ensuring that the RFC addresses
the arguments on both sides and contains all the relevant information
for making a decision? Otherwise many contributors (myself included)
just end up feeling unheard, unhappy, and unconfident that the right
choice is being made.

Derick was trying to be good and meet my beta3 deadline. Fortunately, I
gave him that deadline (while thinking RC1) knowing some kind of bullshit
like this would come up and LO AND BEHOLD here we are. So the good news is
that we actually have a spare two weeks.

With this in mind, I'd like to respectfully make the following
requests:

Defer voting until the two week discussion period is complete
(Tuesday, August 18).

I'd say as late as the 21st. Minimize doubt in the process.

Include a ranked voting option for @: and mention its pros and
cons (it is equally concise as @@ with no BC break, but is somewhat
harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1

Glancing at beberlei's reply, I do agree that @: is coming slightly out of
left field. However, we're using a STV system, so might as well go wild
with the options (within reason). HOWEVER, any option included is going to
need the same care applied as you outline in #3 and #4 below.

Add a Backward Incompatible Changes section with examples of the
code that the different syntax options would break.

More information is better than less. +1

Re (berberlei) """Derick and I are working on this section to update the
RFC later today. We didn't consider this relevant, because the mitigation
steps for all of them is the same: a project wide search and replace to
insert a space"""

Agree that I wouldn't have thought it necessary. These "breaks" are
trivial for a few lines of script to find and fix.

Add a Discussion section briefly summarizing the arguments that
have come up on list. In particular this should include:
a) Tyson's examples of #[] changing the meaning of code in
unexpected ways between PHP 7 and 8 (e.g. a parameter
attribute would remove the parameter when run on PHP 7).
b) An example of the downside of grouping, where it causes
unnecessary diff noise when adding or removing a second
attribute on its own line.
I'd be willing to help draft this section if the RFC authors so desire.

I say "don't ask to ask", just send some suggested text (or put up a gist)
and let them copy it in if they want.

Derick and Benjamin (and Sara), are these requests reasonable? If the

RFC follows the discussion period rule and contains all the relevant
information, I will be much more confident that it is resulting in
the best long term outcome (and I think this would speak for many
others on list as well).

Honestly, the current end date is fine, because the intent of the rule is
met. However, I do like that you're seeking a solution which helps to put
concerns to rest.
The only part which irks me is that we have 50-some votes already cast that
would be thrown out and have to be redone, and that's on what is already
the 3rd vote on this syntax.
I'm vote fatigued, personally. However, we're going to have to live with
this syntax forever once it's out, so we should believe that we believe in
it.

-Sara

3 years ago by Theodore Brown — view source

unread

I was very surprised that it went to vote less than six days after
the discussion period started, right after the weekend no less,
before I had a chance to submit my patch to include the @: syntax.

Yes. Derick fucked up the letter of the rule here. His intentions
were good and reasonable (God knows we've discussed this agonizing
topic for far longer than two weeks), but taking the RFC in question
in a vacuum, it is well under two weeks. By the intent of the rule,
he's fine. This has been discussed exhaustively.

How can the vote result be considered legitimate or binding?

Exhaustingly, I do agree. Contentious times call for careful outcomes.

With this in mind, I'd like to respectfully make the following
requests:

Defer voting until the two week discussion period is complete
(Tuesday, August 18).

I'd say as late as the 21st. Minimize doubt in the process.

Include a ranked voting option for @: and mention its pros and
cons (it is equally concise as @@ with no BC break, but is somewhat
harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1

Glancing at beberlei's reply, I do agree that @: is coming slightly
out of left field. However, we're using a STV system, so might as
well go wild with the options (within reason). HOWEVER, any option
included is going to need the same care applied as you outline in #3
and #4 below.

Thanks Sara. So it sounds like voting will be stopped/reset until the
21st (a week from today), to give time to update the RFC and include
the @: syntax option in the STV polls?

Add a Backward Incompatible Changes section with examples of the
code that the different syntax options would break.

More information is better than less. +1

Add a Discussion section briefly summarizing the arguments that
have come up on list. In particular this should include:
a) Tyson's examples of #[] changing the meaning of code in
unexpected ways between PHP 7 and 8 (e.g. a parameter
attribute would remove the parameter when run on PHP 7).
b) An example of the downside of grouping, where it causes
unnecessary diff noise when adding or removing a second
attribute on its own line.
I'd be willing to help draft this section if the RFC authors so desire.

I say "don't ask to ask", just send some suggested text (or put up a
gist) and let them copy it in if they want.

Okay, I drafted an initial summary of discussion arguments here:
https://gist.github.com/theodorejb/2d39eb6e13159fc749f728900edfd0d2

Honestly, the current end date is fine, because the intent of the rule
is met. However, I do like that you're seeking a solution which helps
to put concerns to rest. The only part which irks me is that we have
50-some votes already cast that would be thrown out and have to be
redone, and that's on what is already the 3rd vote on this syntax.
I'm vote fatigued, personally. However, we're going to have to live
with this syntax forever once it's out, so we should believe that we
believe in it.

Agreed. Regardless of final syntax outcome, ensuring the process isn't
rushed can provide confidence that the right decision is being made.

Kind regards,
Theodore

3 years ago by Derick Rethans — view source

unread

Derick was trying to be good and meet my beta3 deadline.

And I even got that date wrong by a week. Oops.

Fortunately, I gave him that deadline (while thinking RC1) knowing
some kind of bullshit like this would come up and LO AND BEHOLD here
we are. So the good news is that we actually have a spare two weeks.

On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown theodorejb@outlook.com
wrote:

Include a ranked voting option for @: and mention its pros and
cons (it is equally concise as @@ with no BC break, but is somewhat
harder to type). Patch link:
https://github.com/theodorejb/php-src/pull/1

Glancing at beberlei's reply, I do agree that @: is coming slightly
out of left field. However, we're using a STV system, so might as
well go wild with the options (within reason). HOWEVER, any option
included is going to need the same care applied as you outline in #3
and #4 below.

I would like to point out that as the main premise of the RFC was that
the chosen syntax had no ending delimiter, I would say that any new
suggested syntax should have one before I would be willing to consider
adding it.

Derick and Benjamin (and Sara), are these requests reasonable? If
the RFC follows the discussion period rule and contains all the
relevant information, I will be much more confident that it is
resulting in the best long term outcome (and I think this would
speak for many others on list as well).

Honestly, the current end date is fine, because the intent of the rule
is met. However, I do like that you're seeking a solution which helps
to put concerns to rest.

The only part which irks me is that we have 50-some votes already cast
that would be thrown out and have to be redone, and that's on what is
already the 3rd vote on this syntax.

I'm vote fatigued, personally. However, we're going to have to live
with this syntax forever once it's out, so we should believe that we
believe in it.

As I've said, I have no problems with extending the time by the week
and a bit that I missed. I disagree about having to stop, wipe, and
revote. As you said, vote fatigue.

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

3 years ago by Theodore Brown — view source

unread

Derick and Benjamin (and Sara), are these requests reasonable? If
the RFC follows the discussion period rule and contains all the
relevant information, I will be much more confident that it is
resulting in the best long term outcome (and I think this would
speak for many others on list as well).

Honestly, the current end date is fine, because the intent of the rule
is met. However, I do like that you're seeking a solution which helps
to put concerns to rest.

The only part which irks me is that we have 50-some votes already cast
that would be thrown out and have to be redone, and that's on what is
already the 3rd vote on this syntax.

I'm vote fatigued, personally. However, we're going to have to live
with this syntax forever once it's out, so we should believe that we
believe in it.

As I've said, I have no problems with extending the time by the week
and a bit that I missed. I disagree about having to stop, wipe, and
revote. As you said, vote fatigue.

Hi Derick and Sara,

I don't think it's reasonable to simply extend the period, when the
RFC has been significantly updated to include important details that
were missing when most people cast their vote. Otherwise the vote
result does not reflect the contents of the RFC, and therefore cannot
be considered valid.

If vote fatigue is really the most important consideration here,
would this RFC have been brought to vote in the first place?

Regards,
Theodore

3 years ago by michal.brzuchalski@gmail.com — view source

unread

Hi Theodore,

pt., 14 sie 2020, 22:16 użytkownik Theodore Brown theodorejb@outlook.com
napisał:

Derick and Benjamin (and Sara), are these requests reasonable? If
the RFC follows the discussion period rule and contains all the
relevant information, I will be much more confident that it is
resulting in the best long term outcome (and I think this would
speak for many others on list as well).

Honestly, the current end date is fine, because the intent of the rule
is met. However, I do like that you're seeking a solution which helps
to put concerns to rest.

The only part which irks me is that we have 50-some votes already cast
that would be thrown out and have to be redone, and that's on what is
already the 3rd vote on this syntax.

I'm vote fatigued, personally. However, we're going to have to live
with this syntax forever once it's out, so we should believe that we
believe in it.

As I've said, I have no problems with extending the time by the week
and a bit that I missed. I disagree about having to stop, wipe, and
revote. As you said, vote fatigue.

Hi Derick and Sara,

I don't think it's reasonable to simply extend the period, when the
RFC has been significantly updated to include important details that
were missing when most people cast their vote. Otherwise the vote
result does not reflect the contents of the RFC, and therefore cannot
be considered valid.

If vote fatigue is really the most important consideration here,
would this RFC have been brought to vote in the first place?

I don't think there's anything significant changed in the RFC. I really
doubt the vote result will change significantly.

Currently you're the only one who wants to wipe the vote and there is no
much voices willing to follow your proposal.

Personally I think extending the vote by additional week is fair enough.

Cheers,
Michał Marcin Brzuchalski

3 years ago by Chris Riley — view source

unread

On Sat, 15 Aug 2020 at 10:54, Michał Marcin Brzuchalski <
michal.brzuchalski@gmail.com> wrote:

Hi Theodore,

pt., 14 sie 2020, 22:16 użytkownik Theodore Brown theodorejb@outlook.com
napisał:

Derick and Benjamin (and Sara), are these requests reasonable? If
the RFC follows the discussion period rule and contains all the
relevant information, I will be much more confident that it is
resulting in the best long term outcome (and I think this would
speak for many others on list as well).

Honestly, the current end date is fine, because the intent of the
rule
is met. However, I do like that you're seeking a solution which
helps
to put concerns to rest.

The only part which irks me is that we have 50-some votes already
cast
that would be thrown out and have to be redone, and that's on what is
already the 3rd vote on this syntax.

I'm vote fatigued, personally. However, we're going to have to live
with this syntax forever once it's out, so we should believe that we
believe in it.

As I've said, I have no problems with extending the time by the week
and a bit that I missed. I disagree about having to stop, wipe, and
revote. As you said, vote fatigue.

Hi Derick and Sara,

I don't think it's reasonable to simply extend the period, when the
RFC has been significantly updated to include important details that
were missing when most people cast their vote. Otherwise the vote
result does not reflect the contents of the RFC, and therefore cannot
be considered valid.

If vote fatigue is really the most important consideration here,
would this RFC have been brought to vote in the first place?

I don't think there's anything significant changed in the RFC. I really
doubt the vote result will change significantly.

Currently you're the only one who wants to wipe the vote and there is no
much voices willing to follow your proposal.

Personally I think extending the vote by additional week is fair enough.

Cheers,
Michał Marcin Brzuchalski

On the BC breaks front, I actually ended up using @[] in some code
yesterday and PHP Storm already (incorrectly) flagged it as an error.
[image: image.png]
So maybe, inadvertently, not as bad as we think it is?

~C

3 years ago by Andreas Leathley — view source

unread

I don't think there's anything significant changed in the RFC. I really
doubt the vote result will change significantly.

Currently you're the only one who wants to wipe the vote and there is no
much voices willing to follow your proposal.

Personally I think extending the vote by additional week is fair enough.

Next to Theodore, at least 4 other people in this mailing list have
stated that they think the RFC process should be followed as stated in
the RFC documents (with proper time for discussion and voting, which was
clearly not adhered to) and/or that there is important information
missing in the RFC, which both should lead to a change of the RFC and a
revote.

I am a bit surprised at how casually the RFC process is interpreted - it
is the basis of how decisions are made for PHP, yet multiple people have
already stated they don't really feel like following the process as
described/agreed upon, one of them Derick, a long-time member of PHP
Internals, who I would think would want to be a role model for the
process. Why even have an RFC process, if parts of it can be ignored
depending on the mood of some of its more influential members? Does this
behavior inspire confidence in PHP as a language?

By the way, the RFC has not yet changed and is still incomplete as of
now, and updating it at this time would probably not do much - because
how many people re-read an RFC where they already cast the vote? It is
unexpected that an RFC is heavily changed after voting has initiated -
you would expect it to be complete at that time.

3 years ago by michal.brzuchalski@gmail.com — view source

unread

Hi Andreas,

sob., 15 sie 2020, 12:24 użytkownik Andreas Leathley a.leathley@gmx.net
napisał:

I don't think there's anything significant changed in the RFC. I really
doubt the vote result will change significantly.

Currently you're the only one who wants to wipe the vote and there is no
much voices willing to follow your proposal.

Personally I think extending the vote by additional week is fair enough.

Next to Theodore, at least 4 other people in this mailing list have
stated that they think the RFC process should be followed as stated in
the RFC documents (with proper time for discussion and voting, which was
clearly not adhered to) and/or that there is important information
missing in the RFC, which both should lead to a change of the RFC and a
revote.

If you wanna follow democratic rules then first of all 4 is not a quorum.
Secondly, you should be fine with additional voting about stopping current
RFC vote, right?

Cheers,
Michał Marcin Brzuchalski

3 years ago by Andreas Leathley — view source

unread

If you wanna follow democratic rules then first of all 4 is not a quorum.
Secondly, you should be fine with additional voting about stopping current
RFC vote, right?

The RFC process has been agreed upon by the people involved with PHP. It
does not matter if only one person complains about a rule violation, it
should be taken seriously, as the PHP project publicly states that it
follows this kind of RFC process. And there was a democratic vote on the
RFC process.

You seem to mix different concerns - there is no need for a quorum when
agreed upon rules are violated. If you steal a purse, then the people of
your country do not have to have a vote if that is a crime - it was
agreed upon beforehand that it is.

3 years ago by tyson andre — view source

unread

Hi Internals,

Next to Theodore, at least 4 other people in this mailing list have
stated that they think the RFC process should be followed as stated in
the RFC documents (with proper time for discussion and voting, which was
clearly not adhered to) and/or that there is important information
missing in the RFC, which both should lead to a change of the RFC and a
revote.

I am a bit surprised at how casually the RFC process is interpreted - it
is the basis of how decisions are made for PHP, yet multiple people have
already stated they don't really feel like following the process as
described/agreed upon, one of them Derick, a long-time member of PHP
Internals, who I would think would want to be a role model for the
process. Why even have an RFC process, if parts of it can be ignored
depending on the mood of some of its more influential members? Does this
behavior inspire confidence in PHP as a language?

By the way, the RFC has not yet changed and is still incomplete as of
now, and updating it at this time would probably not do much - because
how many people re-read an RFC where they already cast the vote? It is
unexpected that an RFC is heavily changed after voting has initiated -
you would expect it to be complete at that time.

I also want a revote.

I agree that the RFC process should be followed,
the original RFC was incomplete and did not follow that process,
and updating the RFC would probably not do much.
From https://wiki.php.net/rfc/howto

Listen to the feedback, and try to answer/resolve all questions.
Update your RFC to document all the issues and discussions.
Cover both the positive and negative arguments. Put the RFC URL into all your replies.

The previous RFC https://wiki.php.net/rfc/shorter_attribute_syntax
by Theodore was a good example of documenting all of the issues and discussions at the time the vote started. The new RFC isn't.

First, the RFC https://wiki.php.net/rfc/shorter_attribute_syntax_change
was started without even describing the terms in the syntax table,
or a discussion section, or describing the cons (and pros) of #[].
Those and the discussion section were added later by others and the RFC authors,
after the majority of votes were made.

I'd think that https://externals.io/message/111312#111334 was not covered adequately,
as I mentioned in https://externals.io/message/111416#111508
I had also brought up prior to the vote that
"This RFC mentions objections to @@ but not objections to other syntaxes."
(in sentences) but received no reply or acknowledgement from the RFC authors.

Second, the RFC does not link to the voting announcement or discussion prior to the RFC announcement.
There have been over 85 emails in the vote announcement(https://externals.io/message/111416)
and 46 in the rfc discussion (https://externals.io/message/111218) so far,
but neither thread was linked from https://wiki.php.net/rfc/shorter_attribute_syntax_change#references
at the time of writing or when the vote started.
So suggesting that everyone reading the RFC would be aware
of the objections in the RFC discussion emails or vote emails is hard to believe.
(I had tried to avoid repeating arguments I made in RFC discussion in the RFC announcement email. Others likely did so as well.)
Instead, it would be more practical for the RFC authors to fully document
the positive and negative arguments before the vote started.

Third, this RFC results are currently close in the number of voters who rank @[] before/after #[],
so I'd expect errors made in the RFC to significantly bias results towards #[].
The pros and cons of #[] vs @[] weren't described in the RFC with discussion and code examples
when the vote started and the majority of votes were cast.
I don't want major language votes made on the basis of an RFC with process errors or omissions that were known before the RFC started,
now or as a precedent for future votes.

P.S. the RFC introduction also states that "The main concern is that @@ has no ending symbol
and it's inconsistent with the language that it would be the only declaration or statement
in the whole language that has no ending termination symbol."
I had mentioned this in (https://externals.io/message/111312#111335)
that this statement failed to give concrete examples of problems (e.g. parsing ambiguities)
that the authors believe could be caused in 8.0 or in future releases.
I'd also stated that I think an attribute is neither a declaration nor a statement,
but that could be resolved by including the definition of declaration/statement used by the authors.
There are various syntaxes in PHP with no ending symbols (clone, public, yield).
(I doubt changing this will make a difference since many people prefer #[]/@[] for other reasons,
but still consider that sentence to be misleading.)

Thanks,

Tyson

3 years ago by Peter Bowyer — view source

unread

I also want a revote.

I do too.

Partly because of the rules, but mostly because this discussion has gone on
so long I am now less clear about what is an "ending delimiter" and why it
matters than before.

And whether the begin/end delimiters are part of each attribute, or used
once for all attributes. For example,
https://wiki.php.net/rfc/shorter_attribute_syntax#lack_of_nested_attributes.
Derek and Benjamin's RFC shows no nested examples. Are nested attributes
even a thing now or did they disappear in an earlier RFC? If they are, they
should be featured.

On another topic, parentheses and ending delimiters. I have heard Derek's
distinction, but if we're after a syntax with an ending delimiter then I
would propose compulsory parentheses, which means all syntaxes @@, @:, you
name it, would have one.

If that's unacceptable for solving the "ending delimiter" issue, then
document it in the RFC. It feels there is a lot bound up in the lexing,
either by PHP or by how different people read and understand code. I'm
stabbing in the dark for reasons because it's not been explicit - and it
ought to be.

This is not a comprehensive RFC, and while I'm ambivalent about syntax
(having swung between <<>>, @@ and #[] over time) I do not appreciate
feeling that it's being bounced through. Room 11 is not this list, and
discussions that happen there (as earlier messages talk about) provide
background and context that is missing when reading this RFC and not having
been part of those discussions.

P.S. the RFC introduction also states that *"The main concern is that @@

has no ending symbol
and it's inconsistent with the language that it would be the only
declaration or statement
in the whole language that has no ending termination symbol."*
I had mentioned this in (https://externals.io/message/111312#111335)
that this statement failed to give concrete examples of problems (e.g.
parsing ambiguities)
that the authors believe could be caused in 8.0 or in future releases.
I'd also stated that I think an attribute is neither a declaration nor a
statement,
but that could be resolved by including the definition of
declaration/statement used by the authors.
There are various syntaxes in PHP with no ending symbols (clone,
public, yield).
(I doubt changing this will make a difference since many people prefer
#[]/@[] for other reasons,
but still consider that sentence to be misleading.)

Agreed.

Peter

3 years ago by vorismi3@fel.cvut.cz — view source

unread

I am for stopping the current voting too - because the results are very
different vs. the previous voting, they are almost random and the
discussion is still very hot which violates rule when voting can be
started.

My personal opinion on the attributes is:

allow not grouped syntax (with @@ or @:), because I think it is much
better as code is 2 lines shorter or it is very badly mergeable with
conflicts
comments should stay holy, ie. syntax with "#" is not a good choise,
program should stay unchanged when ~/*.?*/|(?://|#)[^\r\n]~s is
removed

With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,

Michael Voříšek

I also want a revote.

I do too.

Partly because of the rules, but mostly because this discussion has gone on
so long I am now less clear about what is an "ending delimiter" and why it
matters than before.

And whether the begin/end delimiters are part of each attribute, or used
once for all attributes. For example,
https://wiki.php.net/rfc/shorter_attribute_syntax#lack_of_nested_attributes.
Derek and Benjamin's RFC shows no nested examples. Are nested attributes
even a thing now or did they disappear in an earlier RFC? If they are, they
should be featured.

On another topic, parentheses and ending delimiters. I have heard Derek's
distinction, but if we're after a syntax with an ending delimiter then I
would propose compulsory parentheses, which means all syntaxes @@, @:, you
name it, would have one.

If that's unacceptable for solving the "ending delimiter" issue, then
document it in the RFC. It feels there is a lot bound up in the lexing,
either by PHP or by how different people read and understand code. I'm
stabbing in the dark for reasons because it's not been explicit - and it
ought to be.

This is not a comprehensive RFC, and while I'm ambivalent about syntax
(having swung between <<>>, @@ and #[] over time) I do not appreciate
feeling that it's being bounced through. Room 11 is not this list, and
discussions that happen there (as earlier messages talk about) provide
background and context that is missing when reading this RFC and not having
been part of those discussions.

P.S. the RFC introduction also states that *"The main concern is that @@

has no ending symbol
and it's inconsistent with the language that it would be the only
declaration or statement
in the whole language that has no ending termination symbol."*
I had mentioned this in (https://externals.io/message/111312#111335)
that this statement failed to give concrete examples of problems (e.g.
parsing ambiguities)
that the authors believe could be caused in 8.0 or in future releases.
I'd also stated that I think an attribute is neither a declaration nor a
statement,
but that could be resolved by including the definition of
declaration/statement used by the authors.
There are various syntaxes in PHP with no ending symbols (clone,
public, yield).
(I doubt changing this will make a difference since many people prefer
#[]/@[] for other reasons,
but still consider that sentence to be misleading.)

Agreed.

Peter

3 years ago by Benjamin Morel — view source

unread

I am for stopping the current voting too - because the results are very
different vs. the previous voting, they are almost random and the
discussion is still very hot which violates rule when voting can be
started.

For what it's worth, I'm for resetting the voting, too, and restart it once
the discussion has settled a bit. The debate is still very heated, and
quite a lot of people seem to think they haven't been heard or haven't had
the time to contribute.

— Benjamin

3 years ago by Jakob Givoni — view source

unread

This will probably be my only contribution to this thread so I'll keep
it simple:

Am I in favor of a revote? Yes
Can I vote myself? No
Do I think a revote will change anything? No
Have there been any good arguments for why attributes need an ending
delimiter? No

The RFC says that

The main concern is that @@ has no ending symbol and it's inconsistent with the language
that it would be the only declaration or statement in the whole language that has no ending termination symbol.
However, it's clear that attributes are neither a declaration nor a
statement, but metadata about the thing that follows them (unless it's
more attributes or comments).
The ultimate proof of this is that a semicolon after an attribute is illegal.

Do I think attributes need an ending delimiter? No
Would I prefer the @@ syntax? Yes
Do I think @@ is ugly or difficult to type? No
Is it just a subjective matter of personal taste? Yes
Is this whole discussion almost entirely a subjective matter? Yes
Is this email thread, the RFC, the voting and the discussion about
extending it a farce? Yes
Do I mind waiting until 8.1 to have attributes so that it can be done right? No

Godspeed!

Best, Jakob

3 years ago by Benjamin Eberlei — view source

unread

This will probably be my only contribution to this thread so I'll keep
it simple:

Am I in favor of a revote? Yes
Can I vote myself? No
Do I think a revote will change anything? No
Have there been any good arguments for why attributes need an ending
delimiter? No

The RFC says that

The main concern is that @@ has no ending symbol and it's inconsistent
with the language
that it would be the only declaration or statement in the whole language
that has no ending termination symbol.
However, it's clear that attributes are neither a declaration nor a
statement, but metadata about the thing that follows them (unless it's
more attributes or comments).
The ultimate proof of this is that a semicolon after an attribute is
illegal.

I would like to chime in here since this argument is made over and over
again, even though it overlooks an important point. when we say that
attributes are just metadata, then let's compare them to docblocks with
are always enclosed in /** and */ instead of visibility keywords.

This comparison is fair, because doc comments are often multi line and
attributes are as well. When doc comments are single line, they are also
enclosed.

Whereas a comparison with visibility modifiers that are just tokens that
always are followed by a T_WHITESPACE is apples vs oranges, because @@
attributes can be followed by a large set of different things:

@@Foo @@Bar // ends due to T_WHITESPACE with " "
@@Foo // ends due to T_WHITESPACE with "\n"
@@Foo() // ends due to )
@@Foo () // ends with ), the T_WHITESPACE between class and arguments is
valid
@@Foo@@Bar // ends due to new T_ATTRIBUTE
@@Foo()@@Bar // ends due to )
@@Foo
("bar") // ends here in the second line at )
function a_function() {
}

We are working to integrate our arguments in favour of enclosing from that
Derick and I made in this and the previous thread into the RFC at the
moment, as the lack of them is a valid point of criticism.

Additionally, Derick and I are waiting for word from Sara and Gabriel at
the moment, but we suggested to close and reset the vote to wait until the
discussion period is over on Tuesday to accommodate the criticism of us
prematurely starting the vote (by accident, not intentionally). We will
take the time to update the RFC with all discussions from here and the
previous thread with arguments that have come up.

Do I think attributes need an ending delimiter? No
Would I prefer the @@ syntax? Yes
Do I think @@ is ugly or difficult to type? No
Is it just a subjective matter of personal taste? Yes
Is this whole discussion almost entirely a subjective matter? Yes
Is this email thread, the RFC, the voting and the discussion about
extending it a farce? Yes
Do I mind waiting until 8.1 to have attributes so that it can be done
right? No

Godspeed!

Best, Jakob

--

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Paul M. Jones — view source

unread

HI all,

Additionally, Derick and I are waiting for word from Sara and Gabriel at
the moment, but we suggested to close and reset the vote to wait until the
discussion period is over on Tuesday to accommodate the criticism of us
prematurely starting the vote (by accident, not intentionally).

/me furrows brow

If I understand correctly, that means the currently-running vote overlaps with the discussion period? If so, that sounds (again) highly irregular.

The proper thing to do here is a full reset: restart the 2-week discussion period at the moment the current vote is declared null and void, then start a new vote (if the RFC is not withdrawn) after thatn 2-week period.

Basically, the sooner the current vote is explicitly declared null and avoid, the sooner the properly-conducted 2-week discussion period can begin.

--
Paul M. Jones
pmjones@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

3 years ago by Andreas Leathley — view source

unread

/me furrows brow
If I understand correctly, that means the currently-running vote overlaps with the discussion period? If so, that sounds (again) highly irregular.

The proper thing to do here is a full reset: restart the 2-week discussion period at the moment the current vote is declared null and void, then start a new vote (if the RFC is not withdrawn) after thatn 2-week period.

Basically, the sooner the current vote is explicitly declared null and avoid, the sooner the properly-conducted 2-week discussion period can begin.

Restarting the vote in basically 2 days seems a bit crazy to me too -
that would just be as over-hastily as the last time. Again, I don't get
it - Sara suggested the 21st as the earliest date to restart the vote.
Why does everything has to be done so hastily, and how should a proper
discussion happen this way?

Benjamin Eberlei is saying that they are now including the arguments for
enclosing - and then in two days the vote starts? How should a
discussion happen about these points if there is no time for people to
actually think about it and respond? As far as I can tell, that is what
the 14 days of RFC discussion is about, or longer if needed - to discuss
open questions, to include them in the RFC, and make sure a good
decision is made with all pertinent information included.

By the way, the DocBlock argument Benjamin Eberlei is mentioning is not
new - yet annotations in DocBlocks do not need the ending symbol of */ -
that is not what encloses annotations, it is what encloses any possible
comments. In comparison, an attribute always consists of a class name
and then possible parameters, enclosed by parentheses. Peter Bowyer
mentioned that the "ending delimiter" argument has been obfuscated to a
point where the meaning or reason remains unclear, and I agree - this
should be fully explained, discussed and appropriately included in the
RFC. I just looked at the RFC - this remains unclear as of now, and
deserves its own discussion which still has not happened yet.

3 years ago by Jakob Givoni — view source

unread

We are working to integrate our arguments in favour of enclosing from that Derick and I made in this and the previous thread into the RFC at the moment, as the lack of them is a valid point of criticism.

Additionally, Derick and I are waiting for word from Sara and Gabriel at the moment, but we suggested to close and reset the vote to wait until the discussion period is over on Tuesday to accommodate the criticism of us prematurely starting the vote (by accident, not intentionally). We will take the time to update the RFC with all discussions from here and the previous thread with arguments that have come up.

Can I make a suggestion?

Make the new or updated RFC a primary vote on: "Should attributes be
enclosed in delimiters?"
This is what we're really discussing and that would make the intention
and everything that follows much clearer.
Then the secondary votes can be on the preferred block syntax.
Voting no means to keep @@ (unless there's another RFC for voting to
change that for another syntax without ending delimiter).

We've had two RFC's now that both had the primary vote being basically
"Are you ok to vote?" - A vote on whether or not to vote???
Maybe it's not a coincidence that both results were considered
disasters by a big chunk of voters.

The primary vote should be on the RFC and the RFC should have a clear
intention. Once you vote yes to the RFC as a whole, any secondary
votes should be just details - mostly about "taste" so to speak and
anyone voting yes on the primary vote should be happy to accept any
outcome of any secondary vote. If that's not the case, the RFC
smells...

Cheers,
Jakob

3 years ago by Jakob Givoni — view source

unread

Can I make a suggestion?

Make the new or updated RFC a primary vote on: "Should attributes be
enclosed in delimiters?"

Actually, let's add the word "block" in there:
"Should attributes be enclosed in block delimiters?"

Where block delimiters are "matching" (not interpreted in any strict
way) beginning and ending symbols.
This is in opposition to f.ex. the @@ syntax that does have ending
delimiters (you know that it ends when you find a specific token),
whether they are a closing bracket or a white space.

So the question becomes "block syntax" or "non-block syntax".

Best,
Jakob

3 years ago by Peter Bowyer — view source

unread

(Resending, as my @php.net email address never makes it to the list)

Can I make a suggestion?

Make the new or updated RFC a primary vote on: "Should attributes be
enclosed in delimiters?"
This is what we're really discussing and that would make the intention
and everything that follows much clearer.

Having read the updated (and now very good) RFC, I second this suggestion.

It feels like we've spent 2 weeks talking at cross purposes, when a
clear wording of attribute syntax vs attribute delimiter syntax would have
short-circuited much of this discussion.

Then the secondary votes can be on the preferred block syntax.
Voting no means to keep @@ (unless there's another RFC for voting to
change that for another syntax without ending delimiter).

+1.

Peter

3 years ago by Jakob Givoni — view source

unread

The RFC says that

The main concern is that @@ has no ending symbol and it's inconsistent with the language
that it would be the only declaration or statement in the whole language that has no ending termination symbol.
However, it's clear that attributes are neither a declaration nor a
statement, but metadata about the thing that follows them (unless it's
more attributes or comments).
The ultimate proof of this is that a semicolon after an attribute is illegal.

I would like to chime in here since this argument is made over and over again, even though it overlooks an important point. when we say that attributes are just metadata, then let's compare them to docblocks with are always enclosed in /** and */ instead of visibility keywords.

This comparison is fair, because doc comments are often multi line and attributes are as well. When doc comments are single line, they are also enclosed.

Whereas a comparison with visibility modifiers that are just tokens that always are followed by a T_WHITESPACE is apples vs oranges, because @@ attributes can be followed by a large set of different things:

@@Foo @@Bar // ends due to T_WHITESPACE with " "
@@Foo // ends due to T_WHITESPACE with "\n"
@@Foo() // ends due to )
@@Foo () // ends with ), the T_WHITESPACE between class and arguments is valid
@@Foo@@Bar // ends due to new T_ATTRIBUTE
@@Foo()@@Bar // ends due to )
@@Foo
("bar") // ends here in the second line at )
function a_function() {
}

Hi Benjamin,

I'm sorry, but I don't understand your argument.
It's true that annotations used to be enclosed in a docblock, but that
is not an argument for saying that attributes NEEDS to be enclosed in
a block too.
It's also true that attributes can be followed by many different
things, but still it doesn't follow that block enclosing is NECESSARY.
What I'm saying is that there is still no good argument for why
attribute block syntax is better than non-block syntax.
The only argument that was presented in the original RFC was not
convincing, and I pointed out why.
I'm also not saying that non-block syntax is better.
Hence, it seems it's just a matter of taste, so far - unless we get to
see some convincing arguments in the rewritten RFC.

Thanks,
Jakob

3 years ago by Benjamin Eberlei — view source

unread

On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei kontakt@beberlei.de
wrote:

The RFC says that

The main concern is that @@ has no ending symbol and it's
inconsistent with the language
that it would be the only declaration or statement in the whole
language that has no ending termination symbol.
However, it's clear that attributes are neither a declaration nor a
statement, but metadata about the thing that follows them (unless it's
more attributes or comments).
The ultimate proof of this is that a semicolon after an attribute is
illegal.

I would like to chime in here since this argument is made over and over
again, even though it overlooks an important point. when we say that
attributes are just metadata, then let's compare them to docblocks with
are always enclosed in /** and */ instead of visibility keywords.

This comparison is fair, because doc comments are often multi line and
attributes are as well. When doc comments are single line, they are also
enclosed.

Whereas a comparison with visibility modifiers that are just tokens
that always are followed by a T_WHITESPACE is apples vs oranges, because
@@ attributes can be followed by a large set of different things:

@@Foo @@Bar // ends due to T_WHITESPACE with " "
@@Foo // ends due to T_WHITESPACE with "\n"
@@Foo() // ends due to )
@@Foo () // ends with ), the T_WHITESPACE between class and arguments
is valid
@@Foo@@Bar // ends due to new T_ATTRIBUTE
@@Foo()@@Bar // ends due to )
@@Foo
("bar") // ends here in the second line at )
function a_function() {
}

Hi Benjamin,

I'm sorry, but I don't understand your argument.
It's true that annotations used to be enclosed in a docblock, but that
is not an argument for saying that attributes NEEDS to be enclosed in
a block too.
It's also true that attributes can be followed by many different
things, but still it doesn't follow that block enclosing is NECESSARY.
What I'm saying is that there is still no good argument for why
attribute block syntax is better than non-block syntax.
The only argument that was presented in the original RFC was not
convincing, and I pointed out why.

Nobody says it's ultimately necessarry as @@ can work.

The argument does not have to be convincing to everyone as we are not
making decisions by 100% majority.

We are bringing forward a set of arguments why we think end delimiters and
enclosing syntax is better and keeps more options open for the future.

I'm also not saying that non-block syntax is better.
Hence, it seems it's just a matter of taste, so far - unless we get to
see some convincing arguments in the rewritten RFC.

Thanks,
Jakob

3 years ago by Jakob Givoni — view source

unread

Hi Benjamin,

I'm sorry, but I don't understand your argument.
It's true that annotations used to be enclosed in a docblock, but that
is not an argument for saying that attributes NEEDS to be enclosed in
a block too.
It's also true that attributes can be followed by many different
things, but still it doesn't follow that block enclosing is NECESSARY.
What I'm saying is that there is still no good argument for why
attribute block syntax is better than non-block syntax.
The only argument that was presented in the original RFC was not
convincing, and I pointed out why.

Nobody says it's ultimately necessarry as @@ can work.

Thanks for the clarification. This is the first time I've heard
someone from the block-delimiter camp concede that @@ is not
necessarily objectively "terrible" (as you yourself put it almost a
month ago), as it was made out to be.

The question is now if it's reasonable at all to change something for
99% purely subjective reasons (no other substantial fact has been put
forward other than the VIM argument) well past feature freeze (yes I
know it's not a feature, but it's still controversial), even past the
beta3 date. And still without respect for letting the discussion phase
run its course before putting to a vote.

May I remind everybody of a few words long ago from our release manager Sara:

I'm fine with this or any syntax, but FF is 13 days away, you're going to
have to give me something more substantial than "It maybe breaks something
somewhere somehow".

Regards the vote; I don't believe that @@ has been proven unworkable,
however if I'm wrong about that, then the second choice selection from the
last vote would obviously take precedence.

If that's the case, then the solution still seems obvious: Defer attributes
to 8.1. I know a LOT of people will not be happy about that, but it's the most
responsible thing to do if the threat of forking up is that present and
that dangerous.

How did we end up here? What started with "[...] a deep sense of
unease that we collectively made the
wrong decision [...]" may have taken a turn for the worse when it
comes to confidence in the process and the community.
Or is it just me being dramatic? :-D

All the best,
Jakob

3 years ago by Benas IML — view source

unread

On Sun, Aug 16, 2020 at 11:32 AM Benjamin Eberlei kontakt@beberlei.de
wrote:

Hi Benjamin,

I'm sorry, but I don't understand your argument.
It's true that annotations used to be enclosed in a docblock, but that
is not an argument for saying that attributes NEEDS to be enclosed in
a block too.
It's also true that attributes can be followed by many different
things, but still it doesn't follow that block enclosing is NECESSARY.
What I'm saying is that there is still no good argument for why
attribute block syntax is better than non-block syntax.
The only argument that was presented in the original RFC was not
convincing, and I pointed out why.

Nobody says it's ultimately necessarry as @@ can work.

Thanks for the clarification. This is the first time I've heard
someone from the block-delimiter camp concede that @@ is not
necessarily objectively "terrible" (as you yourself put it almost a
month ago), as it was made out to be.

The question is now if it's reasonable at all to change something for
99% purely subjective reasons (no other substantial fact has been put
forward other than the VIM argument) well past feature freeze (yes I

In the future, syntax with an ending delimiter might help us to not run
into new parsing issues like @@ did.

And yes, the future DOES indeed matter. I hate when people who don't
contribute to or maintain the php-src actively try to tell otherwise.

know it's not a feature, but it's still controversial), even past the

beta3 date. And still without respect for letting the discussion phase
run its course before putting to a vote.

May I remind everybody of a few words long ago from our release manager
Sara:

I'm fine with this or any syntax, but FF is 13 days away, you're going to
have to give me something more substantial than "It maybe breaks
something
somewhere somehow".

Regards the vote; I don't believe that @@ has been proven unworkable,
however if I'm wrong about that, then the second choice selection from
the
last vote would obviously take precedence.

If that's the case, then the solution still seems obvious: Defer
attributes
to 8.1. I know a LOT of people will not be happy about that, but it's
the most
responsible thing to do if the threat of forking up is that present and
that dangerous.

How did we end up here? What started with "[...] a deep sense of
unease that we collectively made the
wrong decision [...]" may have taken a turn for the worse when it
comes to confidence in the process and the community.
Or is it just me being dramatic? :-D

All the best,
Jakob

--

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Jakob Givoni — view source

unread

Hi Benas,

The question is now if it's reasonable at all to change something for
99% purely subjective reasons (no other substantial fact has been put
forward other than the VIM argument) well past feature freeze (yes I

In the future, syntax with an ending delimiter might help us to not run into new parsing issues like @@ did.

And yes, the future DOES indeed matter. I hate when people who don't contribute to or maintain the php-src actively try to tell otherwise.

I sincerely hope you're not trying to put words in my mouth. Don't be a d*ck.

Again, in the future we might introduce a new feature that might make
attributes have more complex parts than just an argument list. In this
case, @@ or @: is only going to f*** us up.

It sounds like you want to develop a whole new language inside those
attribute blocks... Not sure that's a good idea either, because, you
know, as they say, the future DOES indeed matter ;-)

Regards,
Jakob

3 years ago by Benas IML — view source

unread

Hi Benas,

On Mon, Aug 17, 2020 at 11:34 PM Benas IML benas.molis.iml@gmail.com
wrote:

The question is now if it's reasonable at all to change something for
99% purely subjective reasons (no other substantial fact has been put
forward other than the VIM argument) well past feature freeze (yes I

In the future, syntax with an ending delimiter might help us to not run
into new parsing issues like @@ did.

And yes, the future DOES indeed matter. I hate when people who don't
contribute to or maintain the php-src actively try to tell otherwise.

I sincerely hope you're not trying to put words in my mouth. Don't be a
d*ck.

I was not referring to you specifically. But if you re-read these past 2
week discussion, most of the people being ignorant on the idea of "future
parsing issues" are people, who aren't maintaining PHP.

Again, in the future we might introduce a new feature that might make
attributes have more complex parts than just an argument list. In this
case, @@ or @: is only going to f*** us up.

It sounds like you want to develop a whole new language inside those
attribute blocks... Not sure that's a good idea either, because, you

No but we won't be able to implement a single new feature to attributes
(besides nested attributes) since anything more complicated (e. g
Benjamin's example) requires an ending delimiter.

know, as they say, the future DOES indeed matter ;-)

Regards,
Jakob

3 years ago by Mike Schinkel — view source

unread

I have been following all the lengthy discussions on this topic hoping the list would come to consensus. And I had been hoping someone would call the following question but since no one else has here goes.

The concept of adding attributes to PHP seemed to sail to acceptance but, if you count the original RFC there have been three (3) different RFCs each with the goal of setting or changing the decided syntax alone.

For every syntax proposed there seems to be a contingent of people who are deeply troubled by it. Given that once a syntax lands in an official release of PHP there are not take backs, moving forward with any syntax where people are so divided seems like a really bad idea.

If we care about future developers being happy enough with the decisions made about PHP to continue choosing PHP that I would think it would be incumbent upon us to find a syntax with a greater level of buy-in.

Should we not:

Postpone inclusion of attributes until PHP 8.1 to ensure that we get a syntax that is reasonable acceptable to large segment of stakeholders?
Optionally have an RFC to ask people to vote on disputed principles, such as "Are ending delimiters important and thus are they required for any selected syntax?"
Then open up the floor for more syntax proposals (that address all the accepted principles in #2) in hopes to find something generally acceptable to a larger segment of stakeholders with a goal of completing by 8.1?

-Mike

3 years ago by Aleksander Machniak — view source

unread

Postpone inclusion of attributes until PHP 8.1

+1

I wonder why my suggestion (somewhere in this thread) didn't get any
attention. Is it because the ship had sailed or it's a terrible idea?

declare(
SomeAttr,
AnotherAttr("Hello world")
)
function someFunc() {
}

It's almost identical to #[] or @[], but it looks like PHP and has no BC
breaks. To me it also sounds good - "declare attribute(s) [for] something".

ps. sorry Mike for a duplicate, I pressed the wrong button.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

3 years ago by David Rodrigues — view source

unread

I really found your idea better than all. Keywork is already reserved, make
sense on this context.

Em ter, 18 de ago de 2020 03:49, Aleksander Machniak alec@alec.pl
escreveu:

Postpone inclusion of attributes until PHP 8.1

+1

I wonder why my suggestion (somewhere in this thread) didn't get any
attention. Is it because the ship had sailed or it's a terrible idea?

declare(
SomeAttr,
AnotherAttr("Hello world")
)
function someFunc() {
}

It's almost identical to #[] or @[], but it looks like PHP and has no BC
breaks. To me it also sounds good - "declare attribute(s) [for] something".

ps. sorry Mike for a duplicate, I pressed the wrong button.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

--

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Benjamin Morel — view source

unread

I wonder why my suggestion (somewhere in this thread) didn't get any
attention. Is it because the ship had sailed or it's a terrible idea?

declare(
SomeAttr,
AnotherAttr("Hello world")
)
function someFunc() {
}

This syntax has its benefits, but IMHO looks a bit clumsy for simple
annotations, and does not make it stand out as an annotation to my eyes:

declare(Inject)
class Foo {
}

But this may be just me.

— Benjamin

3 years ago by Benjamin Eberlei — view source

unread

Postpone inclusion of attributes until PHP 8.1

+1

I wonder why my suggestion (somewhere in this thread) didn't get any
attention. Is it because the ship had sailed or it's a terrible idea?

A suggestion requires a patch, otherwise it's just theoretical.

One problem I see with your suggestion is the conflict in a code like this:

<?php

declare(strict_types=1);
declare(SomeAttr)
function foo() {}

It would probably require another keyword, someone else suggested
"attribute" (conflicts with class Attribute) or "use attribute" (along the
lines of "yleld from") or something.

In any case, without a patch showing viability we cannot consider it.

declare(
SomeAttr,
AnotherAttr("Hello world")
)
function someFunc() {
}

It's almost identical to #[] or @[], but it looks like PHP and has no BC
breaks. To me it also sounds good - "declare attribute(s) [for] something".

ps. sorry Mike for a duplicate, I pressed the wrong button.

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

--

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Benjamin Eberlei — view source

unread

I have been following all the lengthy discussions on this topic hoping the
list would come to consensus. And I had been hoping someone would call the
following question but since no one else has here goes.

The concept of adding attributes to PHP seemed to sail to acceptance but,
if you count the original RFC there have been three (3) different RFCs each
with the goal of setting or changing the decided syntax alone.

For every syntax proposed there seems to be a contingent of people who are
deeply troubled by it. Given that once a syntax lands in an official
release of PHP there are not take backs, moving forward with any syntax
where people are so divided seems like a really bad idea.

If we care about future developers being happy enough with the decisions
made about PHP to continue choosing PHP that I would think it would be
incumbent upon us to find a syntax with a greater level of buy-in.

Should we not:

Postpone inclusion of attributes until PHP 8.1 to ensure that we get a
syntax that is reasonable acceptable to large segment of stakeholders?

All the technically complex decisions are done, tested and decided. The
syntax question is still open, but not critical from a technical
implementation POV. All patches regardless of syntax are extremely similar,
just replacing symbols. The non-technical implications and future related
questions are what is up for decision. The arguments for or against these
categories are by now driving in circles. Postponing to 8.1 does therefore
not bring additional value. A decision has to be made and we have enough
time for that.

Optionally have an RFC to ask people to vote on disputed principles,
such as "Are ending delimiters important and thus are they required for any
selected syntax?"

By voting for a syntax, these questions are answered implicitly.

Then open up the floor for more syntax proposals (that address all the
accepted principles in #2) in hopes to find something generally acceptable
to a larger segment of stakeholders with a goal of completing by 8.1?

-Mike

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by Mike Schinkel — view source

unread

I have been following all the lengthy discussions on this topic hoping the list would come to consensus. And I had been hoping someone would call the following question but since no one else has here goes.

The concept of adding attributes to PHP seemed to sail to acceptance but, if you count the original RFC there have been three (3) different RFCs each with the goal of setting or changing the decided syntax alone.

For every syntax proposed there seems to be a contingent of people who are deeply troubled by it. Given that once a syntax lands in an official release of PHP there are not take backs, moving forward with any syntax where people are so divided seems like a really bad idea.

If we care about future developers being happy enough with the decisions made about PHP to continue choosing PHP that I would think it would be incumbent upon us to find a syntax with a greater level of buy-in.

Should we not:

Postpone inclusion of attributes until PHP 8.1 to ensure that we get a syntax that is reasonable acceptable to large segment of stakeholders?

All the technically complex decisions are done, tested and decided. The syntax question is still open, but not critical from a technical implementation POV. All patches regardless of syntax are extremely similar, just replacing symbols. The non-technical implications and future related questions are what is up for decision. The arguments for or against these categories are by now driving in circles. Postponing to 8.1 does therefore not bring additional value. A decision has to be made and we have enough time for that.

Optionally have an RFC to ask people to vote on disputed principles, such as "Are ending delimiters important and thus are they required for any selected syntax?"

By voting for a syntax, these questions are answered implicitly.

Then may I please be allowed to add another option (or two) to the RFC, in hopes that it will be disliked less by everyone that the level of dislike a set of people have for every option?

I propose we utilize the "use" command but with required parenthesis using examples from my code where I previously simulated attributes:

// class attribute use
use PostType('abc_product'),
TemplateVariable('product'),
VirtualReadonly('id'),
VirtualReadonly('name');
// method attribute use
use PrimaryKey();
An option to the above is we utilize the "use" command w/o required parenthesis but w/attribute modifier, although this is not my preference:
// class attribute use
use attribute PostType('abc_product'),
TemplateVariable('product'),
VirtualReadonly('id'),
VirtualReadonly('name');
// method attribute use
use attribute PrimaryKey;
I have prepared a longer example as a Gist:

https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8 https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8

Appropriateness

The second option is similar to "use function " so while it is not exactly the same, "use" is utilized by three contexts already, two (2) of them w/o a modifier:

1.) providing a local name for a namespace,
2.) providing a local name for a function, and
3.) what is effectively an include() for a trait.

The semantics of "use" works for attributes — i.e. "Use this attribute for the following declaration" — and having a 4th type of use seems like it would fit nicely into the existing language.

I would suggest viewing all the different syntaxes to see who "use AttrFunc()" compares in terms of readability:

https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8 https://gist.github.com/mikeschinkel/4c9cc5ed25d6e7665c0e9c70b3458fc8

Benefits

Short; three (3) characters that — importantly — DO NOT require use of the shift key (which my carpal tunnel would be thankful for.).

1a. The 2nd options should be easy to type with an IDE/editor that supports macros
1b. For example in PhpStorm you could assign ua<tab> to expand to "use attribute "
Has a closing delimiter, the semi-colon.
Supports grouping, using commas just like other uses of the "use" command.
Forward compatible in PHP 7 (I think.)
Uses existing T_USE attribute.
(I do not know if it would change the lexing of remaining tokens)
Does not prevent the nesting of attributes in the future as braces could be used as they currently are with traits

-Mike

3 years ago by Jakob Givoni — view source

unread

I have been following all the lengthy discussions on this topic hoping the list would come to consensus. And I had been hoping someone would call the following question but since no one else has here goes.
[...]

Should we not:

Postpone inclusion of attributes until PHP 8.1 to ensure that we get a syntax that is reasonable acceptable to large segment of stakeholders?

Seems prudent to me.

Optionally have an RFC to ask people to vote on disputed principles, such as "Are ending delimiters important and thus are they required for any selected syntax?"

+1 (I already suggested this)

Then open up the floor for more syntax proposals (that address all the accepted principles in #2) in hopes to find something generally acceptable to a larger segment of stakeholders with a goal of completing by 8.1?

Preferable something without square brackets :-p

But it's hard to go the decent, albeit longer, path when you can
almost smell the short term victory already.

3 years ago by Paul M. Jones — view source

unread

Currently you're the only one who wants to wipe the vote and there is no
much voices willing to follow your proposal.

He's not alone. This whole re-vote on the attribute syntax has been highly irregular.

This vote should be canceled, regarded as null and void; the RFC fully updated with the results of the discussion thus far, including all the notes provided by Theodore; a new 2-week pre-vote discussion initiated; and then a new vote can be initiated after that 2 week period.

--
Paul M. Jones
pmjones@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

3 years ago by tyson andre — view source

unread

Hi internals,

One thing I hadn't thought of before was how this would interact with parameters (with or without constructor property promotion).
Many coding styles would end up putting annotations on the same line for parameters (in addition to closures)
E.g. I've commonly done that and seen that done in Java:
https://stackoverflow.com/questions/30237266/java-parameter-annotations

class X {
    public function __construct(
        @@MyImmutable public bool $x,
        private bool $flag = false,
    ) {}
    public function __construct(
        @[MyImmutable] public bool $x,
        private bool $flag = false,
    ) {}
    // This comments out the first parameter entirely in php7, silently leading to different behavior in php 7
    public function __construct(
        #[MyImmutable] public bool $x,
        private bool $flag = false,
    ) {}
}

As Theodore said, this RFC doesn't include enough examples to give a comprehensive understanding of how #[] would be implemented and what the implementation implies, which the original shorter attribute syntax did https://wiki.php.net/rfc/shorter_attribute_syntax#alternative_syntax

(e.g. this gets parsed as $f1 = $f2 = $object = new foo(); in php 7 and would not warn with your patch (from the mailing list) in php8. No patch for #[Attr] is linked in the RFC document.)

$f1 = #[ExampleAttribute] function () {};
 
$f2 = #[ExampleAttribute] fn() => 1;

$object = new #[ExampleAttribute] class () {};
foo();

Even if the RFC was amended after the vote was started,
I don't think that people who had already voted would see the changes or read all of the numerous emails in this thread.

Changes lexing of remaining tokens indicates that a newly introduced token changes the behaviour of existing tokens.
In the example of #[ the occurance of a # would have previously always signified a comment, but that now changes to become an attribute instead when followed by [.

That's similar to saying that the ?? token would have previously indicated a ? for a nullable type/ternary, but would change to become a null coalescing operator when followed by ?.
It understates/omits mentions of the changes to lexing this can cause, which I mentioned in https://externals.io/message/111218#111239

?php
// This example echoes the rest of the source code in php 7
// and echoes "Test" in php 8.
#[DeprecationReason('reason: <https://some-website/reason?>')]
function main() {}
const APP_SECRET = 'app-secret';
echo "Test\n";

// yields false in php 7, yields a function in php 8
function generator() {
    yield #[MyCustomAttribute('
        false;
        // ']function() {};
}

Regards,

Tyson

3 years ago by Benjamin Eberlei — view source

unread

Following the valid criticisms of us starting the vote too early, we have
closed the vote for this RFC for now.

We look to restart the vote middle next week, so that we can close this
before the Beta 3 release on September 3rd.

We have updated the RFC at
https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we think
covers all the discussion and arguments made in this and the previous
mailing list threads.

Sorry to everyone for causing this hazzle.

Hi,

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The first vote is a vote to say that you have an opinion about attribute
syntax. Make sure to read up on the discussion on the mailinglist if you
haven't done so yet.

The second vote is an STV vote.

In STV you SHOULD rank all choices, but don't pick the same one more
than once, as that will invalidate your vote.

Please have a objective look at the table
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
don't just go by asthetics.

The vote ends August 23, 24:00 UTC.

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

--

To unsubscribe, visit: https://www.php.net/unsub.php

3 years ago by michal.brzuchalski@gmail.com — view source

unread

Hi Benjamin,

niedz., 16 sie 2020, 11:29 użytkownik Benjamin Eberlei kontakt@beberlei.de
napisał:

Following the valid criticisms of us starting the vote too early, we have
closed the vote for this RFC for now.

We look to restart the vote middle next week, so that we can close this
before the Beta 3 release on September 3rd.

We have updated the RFC at
https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we
think
covers all the discussion and arguments made in this and the previous
mailing list threads.

Sorry to everyone for causing this hazzle.

Hi,

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The first vote is a vote to say that you have an opinion about attribute
syntax. Make sure to read up on the discussion on the mailinglist if you
haven't done so yet.

The second vote is an STV vote.

In STV you SHOULD rank all choices, but don't pick the same one more
than once, as that will invalidate your vote.

Please have a objective look at the table
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
don't just go by asthetics.

Thank you for working on this. Recent update doesn't change my vote but
made me even more confident about arguments behind #[] syntax.

The table which compares different syntaxes have an amount of minimum chars
needed for writing attribute but what I've noticed is that it differs when
considering more than 2 attributes in groupped syntax.

What I mean is that @@ requires always 2*N amount of chars which for 3
attributes is 6 while for syntaxes like #[] it is only 3 for N=1 and only
3+N-1 for N>1 which for 3 attributes is only 5 and adds always only 1
additional required chars for next additional attribute due to fact that
grouped syntax requires only one comma "," between attributes.

Cheers,
Michał Marcin Brzuchalski

3 years ago by Peter Bowyer — view source

unread

We have updated the RFC at
https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we
think
covers all the discussion and arguments made in this and the previous
mailing list threads.

Thank you for putting in the work it took to revise the RFC. It's good. I
now understand what the delimiters achieve.

While I don't agree with the first point in "Forcing @@ Attributes to end
with parenthesis does not solve issues" (in this new syntax I'd ban
whitespace) I appreciate the point you are making, and it is sensible for
consistency.

I feel grep'ability has been played down, as unless
@@
MyProject\FooAttr

is allowed (which isn't shown in the codeblock), then it's easier to grep
for @@.+?Foo and know you have a chance of an accurate match (assuming
renaming is not used) than it is with the delimiter syntax.

Sorry to everyone for causing this hazzle.

These things happen. Thank you for taking on-board the feedback and working
on the RFC.

Peter

3 years ago by Sara Golemon — view source

unread

On Sun, Aug 16, 2020 at 4:29 AM Benjamin Eberlei kontakt@beberlei.de
wrote:

Following the valid criticisms of us starting the vote too early, we have
closed the vote for this RFC for now.

We look to restart the vote middle next week, so that we can close this
before the Beta 3 release on September 3rd.

Adding publicly that Gabriel and I have both signed off on this, and that
it should be noted that because the vote will finish at end of day on
September 2nd, any change to syntax resulting from this vote won't actually
show in the beta3 build (which will have been cut on the 1st). So expect
to see the result of this vote, whatever it may be, in the RC1 release.

-Sara

3 years ago by Deleu — view source

unread

As stated by the RFC:

We argue why we should strongly favor a syntax with closing delimiter to

keep consistency with other parts of the language and propose to use #[],
@[], or the original << … >> instead.

Given the desire for a closing delimiter, has @:Attr; been considered (or
even @@Attr;)? Can ; be the closing token as it's already used for
statements as well?

Hi,

I've just opened the vote to make sure we don't make a terrible mistake
with using the @@ syntax for attributes:

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The first vote is a vote to say that you have an opinion about attribute
syntax. Make sure to read up on the discussion on the mailinglist if you
haven't done so yet.

The second vote is an STV vote.

In STV you SHOULD rank all choices, but don't pick the same one more
than once, as that will invalidate your vote.

Please have a objective look at the table
(https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
don't just go by asthetics.

The vote ends August 23, 24:00 UTC.

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

--

To unsubscribe, visit: https://www.php.net/unsub.php

--
Marco Aurélio Deleu

[VOTE] Shorter Attribute Syntax Change

Regards,

Regards,

Regards,

Regards,

Regards,

Regards,

Regards,

Regards,

Best regards, Theodore

Cheers

Cheers

Regards,

Regards,

Regards,

Regards,

Regards,

- it could also be #@, which definitely seems weird at first, but

-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net]

cheers, Derick

-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net]

-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net]

-- Aleksander Machniak Kolab Groupware Developer [https://kolab.org] Roundcube Webmail Developer [https://roundcube.net]

-Mike

Appropriateness

Benefits

Best regards,
Theodore

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

cheers,
Derick

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]

--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]