Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

This is only part of a thread. view whole thread
  111120
July 22, 2020 14:37 carusogabriel@php.net (Gabriel Caruso)
On Wed, 22 Jul 2020 at 14:00, Derick Rethans <derick@php.net> wrote:

> Hi all, > > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > - There are lots of grumbles, both on here, room 11, as well as in the > wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/) > - It has the distinct possibility to cause further parsing issues, akin > to what ended up happening with what Nikita is addressing at > https://wiki.php.net/rfc/namespaced_names_as_token > - There is no "end symbol" to make finding occurences easier. > - It is a syntax *no other language* uses. > - @ is never going to go away, so the possibility of @@ moving to @ is > also 0. > > Please, let's do the sensible and use the Rusty #[...] syntax. > > 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 > > Hello Derick.
I do understand your concerns, and I appreciate that you've reached out. Although we are very close to the Feature Freeze date for PHP 8.0 ( https://wiki.php.net/todo/php80), I wouldn't mind opening an exception for this specific case and let you (or someone), create an RFC proposing to change the syntax of Attributes (https://wiki.php.net/rfc/attributes_v2), and that only! I'm copying PHP 8.0's Release Manager Sara, to hear her opinion on this as well. -- Gabriel Caruso
  111122
July 22, 2020 14:45 joe@joeferguson.me (Joe Ferguson)
Hello, Internals,

I would be happy to author an RFC on replacing @@ with #[] but based on
Larry's comments it sounds like the weighted voting already solved this
issue for us? We as internals just need to decide that @@ isn't a solution
and defer to the next ranked vote? I'd be the first one to +1.

On Wed, Jul 22, 2020 at 9:38 AM Gabriel Caruso <carusogabriel@php.net>
wrote:

> On Wed, 22 Jul 2020 at 14:00, Derick Rethans <derick@php.net> wrote: > > > Hi all, > > > > I know we've voted twice on this already, but are we really sure that > > the @@ syntax is a good idea? > > > > - There are lots of grumbles, both on here, room 11, as well as in the > > wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/) > > - It has the distinct possibility to cause further parsing issues, akin > > to what ended up happening with what Nikita is addressing at > > https://wiki.php.net/rfc/namespaced_names_as_token > > - There is no "end symbol" to make finding occurences easier. > > - It is a syntax *no other language* uses. > > - @ is never going to go away, so the possibility of @@ moving to @ is > > also 0. > > > > Please, let's do the sensible and use the Rusty #[...] syntax. > > > > 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 > > > > > Hello Derick. > > I do understand your concerns, and I appreciate that you've reached out. > > Although we are very close to the Feature Freeze date for PHP 8.0 ( > https://wiki.php.net/todo/php80), I wouldn't mind opening an exception for > this specific case and let you (or someone), create an RFC proposing to > change the syntax of Attributes (https://wiki.php.net/rfc/attributes_v2), > and that only! > > I'm copying PHP 8.0's Release Manager Sara, to hear her opinion on this as > well. > > -- Gabriel Caruso >
-- - Joe Ferguson JoeFerguson.me osmihelp.org
  111124
July 22, 2020 14:48 sebastian@php.net (Sebastian Bergmann)
Am 22.07.2020 um 16:45 schrieb Joe Ferguson:
> We as internals just need to decide that @@ isn't a solution > and defer to the next ranked vote? I'd be the first one to +1.
Makes sense to me; +1.
  111128
July 22, 2020 16:43 d.h.j.takken@freedom.nl (Dik Takken)
On 22-07-2020 16:45, Joe Ferguson wrote:
> I would be happy to author an RFC on replacing @@ with #[] but based on > Larry's comments it sounds like the weighted voting already solved this > issue for us? We as internals just need to decide that @@ isn't a solution > and defer to the next ranked vote? I'd be the first one to +1.
That means we effectively disregard the preferences of the ones who voted for the @@ syntax. We do not know what the @@ voters would have chosen if the choice was between << >> and #[]. In case the @@ voters have a preference for << >> the result could turn out differently. The only way to know is to take another vote. Regards, Dik Takken
  111129
July 22, 2020 16:49 marandall@php.net (Mark Randall)
On 22/07/2020 17:43, Dik Takken wrote:
> That means we effectively disregard the preferences of the ones who > voted for the @@ syntax. We do not know what the @@ voters would have > chosen if the choice was between << >> and #[]. In case the @@ voters > have a preference for << >> the result could turn out differently. The > only way to know is to take another vote.
Yes we do - it was a ranked choice vote where voters selected their first, second and third preferences. If @@ is eliminated, the second choice of all those who voted for it as their first choice is already known. Mark Randall
  111130
July 22, 2020 16:51 derick@php.net (Derick Rethans)
On Wed, 22 Jul 2020, Dik Takken wrote:

> We do not know what the @@ voters would have chosen if the choice was > between << >> and #[]. In case the @@ voters have a preference for > <<>> the result could turn out differently. The only way to know is to > take another vote.
This is something that STV is specifically designed to solve. You rank in order by preference. And @@, <<>>, and #[] were all three options. In your example, these people would have marked @@ as first, <<>> as second, and #[] as third. cheers, Derick
  111135
July 22, 2020 19:24 d.h.j.takken@freedom.nl (Dik Takken)
On 22-07-2020 18:51, Derick Rethans wrote:
> This is something that STV is specifically designed to solve. You rank > in order by preference. And @@, <<>>, and #[] were all three options. > > In your example, these people would have marked @@ as first, <<>> as > second, and #[] as third.
Ah, that was not clear to me. My apologies for the noise. Thanks, Dik