Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111352
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <BYAPR05MB6535AE9831221566469C4503DE4A0@BYAPR05MB6535.namprd05.prod.outlook.com>
 <alpine.DEB.2.23.453.2008060741110.7489@singlemalt.home.derickrethans.nl> <20200806091749.64675445@mcmic-probook.opensides.be>
In-Reply-To: <20200806091749.64675445@mcmic-probook.opensides.be>
Date: Thu, 6 Aug 2020 11:11:43 +0300
Message-ID: <CANeKSiStbGZG+EOVDRfRuVo4MA7th16R-oP7V2xmPj3xHNxs_A@mail.gmail.com>
To: =?UTF-8?Q?C=C3=B4me_Chilliet?= <come.chilliet@fusiondirectory.org>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bc9ee905ac310abf"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000bc9ee905ac310abf
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 6, 2020, 10:18 AM C=C3=B4me Chilliet <
come.chilliet@fusiondirectory.org> wrote:

> Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
> Derick Rethans <derick@php.net> a =C3=A9crit :
> > From the RFC:
> > - No ending delimiter
>
> As said before, it does have an ending delimiter when they are arguments
> since
>  there is the parenthesis around them. When there are no arguments I don=
=E2=80=99t
> see
>  the benefit of an ending delimiter, it=E2=80=99s easy to spot the end of=
 the word.


Ending delimiter MAY help us in the future.

I really, really hate all of those arguments stating "that we should care
only about the present, not the future" and that even though
`#[...]`/`@[...]` might bring benefits in the future, we should still
choose `@@`".

This shows clearly that some people are basing their views on subjective
reasons rather than being objective.

As far as this discussion is going, I see pro-`@@` people just saying
"Arghhh, let's keep @@, it doesn't bring any benefits that other syntaxes
do but we don't need them anyways, let's not speculate future".

It's like saying you can either go through door A and get a free car or
through door B and get the same car and **maybe**, even an additional
1,000$.

We are playing probabilities here but at the moment, no one has said any
substantial argument why `@@` is better and thus, `@[...]` seems like a
better option in the long term.


> > - Doesn't allow grouping
>
> I do not understand this argument, what is the point of grouping for @@?
> Does grouping mean anything special for other syntaxes, or is it just to
> save
>  keystrokes? If it is just to get a more concise syntax when there are
> several
>  attributes, the fact that @@ do not need grouping is a pro, not a con.
>

No, it is not a pro. It's a matter of personal taste. You are basing your
opinion on subjective views which goes against this RFC's principles - to
choose a syntax that is the best based on the benefits it offers.

> - No forwards compat with PHP 7
>
> But no BC break either, while #[] introduces BC break.
>

Not true, technically speaking both `@@` and `#[]` have a BC break. Albeit
`@@` has a smaller one.

But by sacrificing a few very old codebases (that still use `#` not `//`),
we are making sure that we won't run into any parsing problems in the
future. And this is far more important.

> - Not used ny another language
>
> @ is used by a lot of other languages, and @@ is the closest we can get i=
n
> PHP.
>

This is a pointless argument.

`[...]`/`[[...]]` is also used by a lot of languages, `#[...]` and `@[...]`
is the closest we can get to that.

Heck, `@[...]` is the closest to both `@` and `[...]`.

Best regards,
Benas

>

--000000000000bc9ee905ac310abf--