Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel  wrote:
>
> 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:
>
> 1. 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.

> 2. 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)

> 3. 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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Mike Schinkel]

> On Aug 18, 2020, at 6:54 AM, Benjamin Eberlei  wrote:
> 
> On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel  > wrote:
> 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:
> 
> 1. 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.
> 
> 2. 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 


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 


Benefits
---
1. 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 to expand to "use 
attribute "

2. Has a closing delimiter, the semi-colon.

3. Supports grouping, using commas just like other uses of the "use" command.

4. Forward compatible in PHP 7 (I think.)

5. Uses existing T_USE attribute.

6. (I do not know if it would change the lexing of remaining tokens)

7. Does not prevent the nesting of attributes in the future as braces could be 
used as they currently are with traits

-Mike

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Tue, Aug 18, 2020 at 8:49 AM Aleksander Machniak  wrote:

> On 18.08.2020 00:35, Mike Schinkel wrote:
> > 1. 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:


> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Morel]

On Tue, 18 Aug 2020 at 08:49, Aleksander Machniak  wrote:

>
> 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[David Rodrigues]

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 
escreveu:

> On 18.08.2020 00:35, Mike Schinkel wrote:
> > 1. 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel  wrote:

> 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:
>
> 1. 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.

>
> 2. 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.

>
> 3. 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
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Aleksander Machniak]

On 18.08.2020 00:35, Mike Schinkel wrote:
> 1. 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Mike Schinkel]

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:

1. Postpone inclusion of attributes until PHP 8.1 to ensure that we get a 
syntax that is reasonable acceptable to large segment of stakeholders?

2. 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?"

3. 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benas IML]

On Tue, Aug 18, 2020, 1:04 AM Jakob Givoni  wrote:

> Hi Benas,
>
> On Mon, Aug 17, 2020 at 11:34 PM Benas IML 
> wrote:
> >
> > On Tue, Aug 18, 2020, 12:25 AM Jakob Givoni  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
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

Hi Benas,

On Mon, Aug 17, 2020 at 11:34 PM Benas IML  wrote:
>
> On Tue, Aug 18, 2020, 12:25 AM Jakob Givoni  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.

> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benas IML]

On Tue, Aug 18, 2020, 12:25 AM Jakob Givoni  wrote:

> On Sun, Aug 16, 2020 at 11:32 AM Benjamin Eberlei 
> wrote:
> >
> > On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni  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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

On Sun, Aug 16, 2020 at 11:32 AM Benjamin Eberlei  wrote:
>
> On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni  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
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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Sara Golemon]

On Sun, Aug 16, 2020 at 4:29 AM Benjamin Eberlei 
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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 17, 2020 at 2:29 PM Benjamin Eberlei 
wrote:

>
>
> On Mon, Aug 17, 2020 at 10:02 AM Peter Bowyer  wrote:
>
>> On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei 
>> wrote:
>>
>>> 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.
>>
>
> no space is allowed between @@ and name, they have to be in the same line.
> The whitespace between name and argument_list is not currently banned, the
> comparison is to the status quo (since that is not expected to change).
>

Correction, I was made aware that this is not true, a space betwen @@ and
attribute name is allowed at the moment:

@@
   MyProject\FooAttr
function foo() {}

is allowed.

>
> Still I think the grepability has to rest on no assumptions, because
> otherwise you could argue the same for @[] being used non-grouped on one
> line and would have to conclude that this is also grepable.
>
>>
>> Sorry to everyone for causing this hazzle.
>>>
>>
>> These things happen. Thank you for taking on-board the feedback and
>> working on the RFC.
>>
>> Peter
>>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 17, 2020 at 10:02 AM Peter Bowyer  wrote:

> On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei 
> wrote:
>
>> 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.
>

no space is allowed between @@ and name, they have to be in the same line.
The whitespace between name and argument_list is not currently banned, the
comparison is to the status quo (since that is not expected to change).

Still I think the grepability has to rest on no assumptions, because
otherwise you could argue the same for @[] being used non-grouped on one
line and would have to conclude that this is also grepable.

>
> Sorry to everyone for causing this hazzle.
>>
>
> These things happen. Thank you for taking on-board the feedback and
> working on the RFC.
>
> Peter
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei  wrote:

> 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

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

On Sun, 16 Aug 2020 at 07:42, Jakob Givoni  wrote:

> 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Michał Marcin Brzuchalski]

Hi Benjamin,

niedz., 16 sie 2020, 11:29 użytkownik Benjamin Eberlei 
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.
>
> On Mon, Aug 10, 2020 at 10:41 AM Derick Rethans  wrote:
>
> > 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

>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Deleu]

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?

On Mon, Aug 10, 2020 at 10:41 AM Derick Rethans  wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

-- 
Marco Aurélio Deleu

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni  wrote:

> On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei 
> 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
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

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.

On Mon, Aug 10, 2020 at 10:41 AM Derick Rethans  wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei  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.
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

>
> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

>
> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Paul M. Jones]

Hi all,

> On Aug 15, 2020, at 18:27, kont...@beberlei.de wrote:
> 
> The Voring RFC clearly states 2 weeks from the announcement on this list.

Which rule was clearly not followed ...

> If we consider the current vote an instance of human error

... which consideration I agree with ...

> then i dont see how restarting the discussion helps.

... it helps by following the rule: the intervening vote disrupted the 
discussion, which now (to conform to the rule) should restart.

> I spent the whole day incorporating every argument and discussion thread into 
> the new RFC Version to be, so that voters will be fully informed
> by the RFC once the vote re-starts on Tuesday.

I'm very glad to hear that; the vote should not re-start on Tuesday, though, 
since we'll need 2 weeks to discuss these important and substantial revisions.


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 16.08.20 01:07, Paul M. Jones wrote:

/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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[kontakt]

> Am 16.08.2020 um 01:08 schrieb Paul M. Jones :
> 
> HI all,
> 
> 
>> On Aug 15, 2020, at 18:00, Benjamin Eberlei  wrote:
>> 
>> 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.

The Voring RFC clearly states 2 weeks from the announcement on this list. If we 
consider the current vote an instance of human error, then i dont see how 
restarting the discussion helps.

I spent the whole day incorporating every argument and discussion thread into 
the new RFC Version to be, so that voters will be fully informed by the RFC 
once the vote re-starts on Tuesday.
> 
> -- 
> Paul M. Jones
> pmjo...@pmjones.io
> http://paul-m-jones.com
> 
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
> 
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
> 
> 
> 

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Paul M. Jones]

HI all,


> On Aug 15, 2020, at 18:00, Benjamin Eberlei  wrote:
> 
> 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
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Sat, Aug 15, 2020 at 11:47 PM Jakob Givoni  wrote:

> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Morel]

>
> 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Michael Voříšek - ČVUT FEL]

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

On 15 Aug 2020 17:36, Peter Bowyer wrote:


On Sat, 15 Aug 2020 at 16:07, tyson andre  wrote:


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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

On Sat, 15 Aug 2020 at 16:07, tyson andre  wrote:

> 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[tyson andre]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: 

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Paul M. Jones]

> On Aug 15, 2020, at 04:54, Michał Marcin Brzuchalski 
>  wrote:
> 
> 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
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benas IML]

On Sat, Aug 15, 2020, 2:53 PM Björn Larsson 
wrote:

> Den 2020-08-14 kl. 21:23, skrev Derick Rethans:
>
> > On Fri, 14 Aug 2020, Sara Golemon wrote:
> >
> >> 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 
> >> wrote:
> >>> 2. 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.
>
> I think that lack of ending delimiter is not a good enough reason to
> exclude the @: syntax from the RFC and voting. Would be good to
> have the community view on this in order to put this to rest!
>

No, the community view does not matter here. Including `@:` would go
against the core values that this RFC is proposing: an attribute syntax
that has an ending delimiter.


> We have the @@ syntax in the voting and of course that's natural.
>

We have it in the voting poll since it's our current syntax; there are no
other reasons.

Still adding the @: option would in my eyes give a more complete
> view of feasible syntax choices. The far fetched ones should not
> be included of course.
>

Which would go against the entire premise of this RFC. If someone wants
`@:`, he/she should create separate RFC.


> r//Björn L
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Björn Larsson]

Den 2020-08-14 kl. 21:23, skrev Derick Rethans:


On Fri, 14 Aug 2020, Sara Golemon wrote:


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 
wrote:

2. 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.


I think that lack of ending delimiter is not a good enough reason to
exclude the @: syntax from the RFC and voting. Would be good to
have the community view on this in order to put this to rest!

We have the @@ syntax in the voting and of course that's natural.
Still adding the @: option would in my eyes give a more complete
view of feasible syntax choices. The far fetched ones should not
be included of course.

r//Björn L

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 15.08.20 12:35, Michał Marcin Brzuchalski wrote:

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Michał Marcin Brzuchalski]

Hi Andreas,

sob., 15 sie 2020, 12:24 użytkownik Andreas Leathley 
napisał:

> On 15.08.20 11:54, Michał Marcin Brzuchalski wrote:
> > 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 15.08.20 11:54, Michał Marcin Brzuchalski wrote:

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Chris Riley]

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

> Hi Theodore,
>
> pt., 14 sie 2020, 22:16 użytkownik Theodore Brown 
> napisał:
>
> > On Fri, Aug 14, 2020 at 2:23 PM Derick Rethans  wrote:
> >
> > > On Fri, 14 Aug 2020, Sara Golemon wrote:
> > >
> > > > > 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Michał Marcin Brzuchalski]

Hi Theodore,

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

> On Fri, Aug 14, 2020 at 2:23 PM Derick Rethans  wrote:
>
> > On Fri, 14 Aug 2020, Sara Golemon wrote:
> >
> > > > 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

>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Fri, Aug 14, 2020 at 2:23 PM Derick Rethans  wrote:

> On Fri, 14 Aug 2020, Sara Golemon wrote:
> 
> > > 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Derick Rethans]

On Fri, 14 Aug 2020, Sara Golemon wrote:

> 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 
> wrote:

> > 2. 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Fri, Aug 14, 2020 at 9:48 AM Sara Golemon  wrote:

> On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown  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.
> 
> > With this in mind, I'd like to respectfully make the following
> > requests:
> >
> > 1. 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.
> 
> > 2. 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?

> > 3. 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
> 
> > 4. 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Fri, Aug 14, 2020 at 9:16 AM Benjamin Eberlei  wrote:

> On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown  wrote:
> > 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:
> > 
> > 1. 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.

> > 2. 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.

> > 3. 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.

> > 4. 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"
> 

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Sara Golemon]

On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown 
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:
>
> 1. 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.


> 2. 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.


> 3. 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.


> 4. 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Joe Ferguson]

On 8/14/2020 09:34, Paul M. Jones wrote:

(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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Paul M. Jones]

> On Aug 14, 2020, at 09:16, Benjamin Eberlei  wrote:
> 
> 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
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown 
wrote:

> On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison 
> 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:
>
> 1. 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.

>
> 2. 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 @:

>
> 3. 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).


> 4. 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison  
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:

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

2. 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

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

4. 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 14.08.20 03:41, Levi Morrison via internals wrote:

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 

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Levi Morrison via internals]

> 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...

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Paul M. Jones]

> On Aug 13, 2020, at 10:44, Theodore Brown  wrote:
> 
> 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
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[tyson andre]

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: ')]
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Thu, Aug 13, 2020 at 8:47 AM Andreas Leathley  wrote:

> On 13.08.20 15:17, Theodore Brown wrote:
> > 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

[1]: https://wiki.php.net/rfc/shorter_attribute_syntax_change?rev=1596407928
[2]: https://externals.io/message/111312#111312
[3]: https://wiki.php.net/rfc/shorter_attribute_syntax#alternative_syntax
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 13.08.20 15:17, Theodore Brown wrote:

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Michał Marcin Brzuchalski]

Hi Theodore,

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

> On Thu, Aug 13, 2020 at 3:13 AM Michał Marcin Brzuchalski <
> michal.brzuchal...@gmail.com> wrote:
>
> > Hi Theodore,
> >
> > śr., 12 sie 2020 o 18:36 Theodore Brown 
> napisał(a):
> > > On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon  wrote:
> > >
> > > > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown 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.
> > >
> > > 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
> > >
> > > [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
> >
> > 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. 

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Thu, Aug 13, 2020 at 3:13 AM Michał Marcin Brzuchalski 
 wrote:

> Hi Theodore,
> 
> śr., 12 sie 2020 o 18:36 Theodore Brown  napisał(a):
> > On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon  wrote:
> > 
> > > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown 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.
> > 
> > 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
> > 
> > [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
> 
> 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. 

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Côme Chilliet]

Le Thu, 13 Aug 2020 10:13:16 +0200,
Michał Marcin Brzuchalski  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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Michał Marcin Brzuchalski]

Hi Theodore,

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

> On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon  wrote:
>
> > On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown 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.
>
> 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
>
> [1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals


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

[1]: https://externals.io/message/111218#111254
[2]: https://wiki.php.net/rfc#declined
[3]: https://externals.io/message/110640#110819
[4]: https://externals.io/message/01#01
[5]: https://externals.io/message/01#32

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

On Wed, Aug 12, 2020 at 9:08 PM Rowan Tommins  wrote:
>
> On 12 August 2020 19:03:02 BST, Jakob Givoni  wrote:
> >> > Is
> >> >
> >> > 
> >> >
> >> > 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On 12 August 2020 19:03:02 BST, Jakob Givoni  wrote:
>> > Is
>> >
>> > 
>> >
>> > 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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Jakob Givoni]

On Tue, Aug 11, 2020 at 3:03 PM Theodore Brown  wrote:
>
> On Tue, Aug 11, 2020 at 7:26 AM Chris Riley  wrote:
>
> > On Tue, 11 Aug 2020 at 13:21, Derick Rethans  wrote:
> >
> > > On Tue, 11 Aug 2020, Chris Riley wrote:
> > >
> > > > 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
> >
> > 
> >
> > 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Wed, Aug 12, 2020 at 10:25 AM Sara Golemon  wrote:

> On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown 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.

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

[1]: https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 12.08.20 17:25, Sara Golemon wrote:

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Derick Rethans]

On Wed, 12 Aug 2020, Sara Golemon wrote:

> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Kalle Sommer Nielsen]

Den ons. 12. aug. 2020 kl. 18.29 skrev Paul M. Jones :
> It's premature. If we can't follow our own rules, why even have them?

Agreed

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Paul M. Jones]

> On Aug 12, 2020, at 10:25, Sara Golemon  wrote:
> 
> 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
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Sara Golemon]

On Wed, Aug 12, 2020 at 9:48 AM Theodore Brown 
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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:

>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

[1]: https://wiki.php.net/RFC/voting#discussion_period
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Aleksander Machniak]

On 11.08.2020 16:54, Sara Golemon wrote:
>> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Nikita Popov]

On Tue, Aug 11, 2020 at 6:26 PM Andreas Leathley  wrote:

> On 11.08.20 18:07, Sara Golemon wrote:
> > 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Larry Garfield]

On Tue, Aug 11, 2020, at 11:54 AM, Theodore Brown wrote:
> On Tue, Aug 11, 2020 at 11:36 AM Rowan Tommins  
> wrote:

> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Tue, 11 Aug 2020 at 17:54, Theodore Brown  wrote:

>
> 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]

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 11.08.20 18:38, Sara Golemon wrote:

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, Aug 11, 2020 at 11:36 AM Rowan Tommins  wrote:

> On Tue, 11 Aug 2020 at 17:07, Theodore Brown  wrote:
> 
> > > > 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Sara Golemon]

On Tue, Aug 11, 2020 at 11:38 AM Sara Golemon  wrote:

> 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

>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Sara Golemon]

On Tue, Aug 11, 2020 at 11:25 AM Andreas Leathley 
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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Tue, 11 Aug 2020 at 17:07, Theodore Brown  wrote:

>
> 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<> 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]

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 11.08.20 18:07, Sara Golemon wrote:

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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Sara Golemon]

On Tue, Aug 11, 2020 at 10:07 AM guilhermebla...@gmail.com <
guilhermebla...@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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, Aug 11, 2020 at 10:39 AM Rowan Tommins  wrote:

> On Tue, 11 Aug 2020 at 16:31, Theodore Brown  wrote:
> 
> > 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Matteo Beccati]

Hi,

On 11/08/2020 12:10, Chris Riley wrote:
> 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/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Tue, 11 Aug 2020 at 16:31, Theodore Brown  wrote:

>
> 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]

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Paul M. Jones]

> On Aug 11, 2020, at 09:54, Sara Golemon  wrote:
> 
> On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:
> 
>> 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
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Tue, 11 Aug 2020 at 16:07, guilhermebla...@gmail.com <
guilhermebla...@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]

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, Aug 11, 2020 at 8:37 AM Derick Rethans  wrote:

> On Tue, 11 Aug 2020, Theodore Brown 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.
> 
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[guilhermebla...@gmail.com]

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,

On Tue, Aug 11, 2020 at 10:55 AM Sara Golemon  wrote:
>
> On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:
>
> > 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Sara Golemon]

On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans  wrote:

> 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

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Tue, 11 Aug 2020 at 14:15, Peter Bowyer 
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:

~~  :  !
@@  (  )


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]

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Andreas Leathley]

On 11.08.20 15:15, Lynn wrote:

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 <>
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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Derick Rethans]

On Tue, 11 Aug 2020, Theodore Brown 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.

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Rowan Tommins]

On Tue, 11 Aug 2020 at 14:16, Lynn  wrote:

> 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]

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Lynn]

On Tue, Aug 11, 2020 at 3:03 PM Theodore Brown 
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 <>
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.

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Peter Bowyer]

On Mon, 10 Aug 2020 at 15:41, Peter Bowyer 
wrote:

>
>
> On Mon, 10 Aug 2020 at 14:59, Derick Rethans  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:
>
> <><>(
> <><>(<>),
> 42
> )
>
> and:
>
> <>[<>(
> <>[<>(<>)],
> 42
> )]
>
> in terms of parsing, use etc?
>
> Peter
>

Anyone?

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

Peter

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Theodore Brown]

On Tue, Aug 11, 2020 at 7:26 AM Chris Riley  wrote:

> On Tue, 11 Aug 2020 at 13:21, Derick Rethans  wrote:
> 
> > On Tue, 11 Aug 2020, Chris Riley wrote:
> >
> > > 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
> 
> 
> 
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Chris Riley]

On Tue, 11 Aug 2020 at 13:21, Derick Rethans  wrote:

> On Tue, 11 Aug 2020, Chris Riley wrote:
>
> > 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



on it's own an error?

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Derick Rethans]

On Tue, 11 Aug 2020, Chris Riley wrote:

> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Chris Riley]

On Tue, 11 Aug 2020 at 12:40, Matteo Beccati  wrote:

> Hi,
>
> On 11/08/2020 12:10, Chris Riley wrote:
> > 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