Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111617
MIME-Version: 1.0
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <CAEPJdumGf0r9Jwb9nBiAEFPoELP4ckx_OJo4HCHhAPgUPEMqQA@mail.gmail.com>
 <CAJmjfvWSiD=C8W+NLJM_391u1+-TXU1u-+KN9c1OcXob1qON0w@mail.gmail.com>
 <CANeKSiTB7E0FCCeWKkYoUbeG0pgcf0fzn0czpOs5s9qCG7exCw@mail.gmail.com> <8f71e02f-cdc5-8c1b-5e92-01c13a18ee09@gmx.net>
In-Reply-To: <8f71e02f-cdc5-8c1b-5e92-01c13a18ee09@gmx.net>
Date: Wed, 19 Aug 2020 00:16:56 +0300
Message-ID: <CANeKSiTuiHPOHsgAxCUuoEx35wopRm=xsdgDbOJWcy13SrNS5w@mail.gmail.com>
To: Andreas Leathley <a.leathley@gmx.net>
Cc: Jakob Givoni <jakob@givoni.dk>, Benjamin Eberlei <kontakt@beberlei.de>, 
	Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f6f0b605ad2d685c"
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: benas.molis.iml@gmail.com (Benas IML)

--000000000000f6f0b605ad2d685c
Content-Type: text/plain; charset="UTF-8"

On Tue, Aug 18, 2020, 1:42 AM Andreas Leathley <a.leathley@gmx.net> wrote:

> On 18.08.20 00:03, Benas IML wrote:
> > And then boo-yah, 6 months later we want to implement a cool new
> > feature to
> > attributes (a lot of examples were said before, ain't repeating myself)
> but
> > we can't :(( because there is no ending delimiter and thus, we will run
> > into parsing issues.
>
> Both @{} and @@{} would be possible as a future extension of the syntax
> and would have no BC break at all, if extending the syntax is something
> that would/should happen - just as possible suggestions.


Introducing `@@{}` would:
* be against `@@` "conciseness" ideology and would be longer than
`@[]`/`#[]`
* what's the point of creating a new syntax if we can just pick `@[]`/`#[]`?


> It is likely though that the vast majority of attribute usage will be
> quite simple (like the ones we have today with annotations: for routes,
> for validation, for ORMs), so having a simple syntax for a feature which
> is mostly used in a straightforward way does not seem that crazy.
>

"It is likely" is key here. So far, the only "positive" thing I have seen
about `@@` is smaller BC break which is albeit questionable since I was
able to find only 2 instances of a BC break for `@[]` (when searching top
Composer packages).

As for other "pros", let's be honest, no one cares that `@@` is 2
characters whereas `@[]` is 3 characters.


> And about your condescending remark of people trying to add to the
> discussion who have not "proven themselves in the PHP source code":
> Having a discussion with people who have different viewpoints seems like
> a big benefit for any project, because it is impossible to be an expert
>

At the end of the day, the so called "experts" are maintaining PHP source
code.

Having an opinion is okay but being ignorant about the issues which might
arise to the maintainers is completely unacceptable.

at C code, php-src, PHP code, all PHP frameworks, all the PHP libraries,
> and all the ways PHP is used today - yet all that can be relevant for
> language changes and the actual usage of new features, including the
> syntax.
>

Best regards,
Benas

--000000000000f6f0b605ad2d685c--