Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110376
MIME-Version: 1.0
References: <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
Date: Thu, 4 Jun 2020 18:19:23 +0100
Message-ID: <CALKiJKrwUA4Mo4HmHVL6ChaQSidpgS3jmc3fqdbZgnob4gk0zg@mail.gmail.com>
To: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000042e21c05a7455909"
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: rowan.collins@gmail.com (Rowan Tommins)

--00000000000042e21c05a7455909
Content-Type: text/plain; charset="UTF-8"

On Thu, 4 Jun 2020 at 00:55, Theodore Brown <theodorejb@outlook.com> wrote:

> https://wiki.php.net/rfc/shorter_attribute_syntax
>
> The goal is not to bikeshed over subjective syntax preferences,
> but to address several concrete shortcomings related to verbosity,
> nested attributes, confusion with generics and other tokens, and
> dissimilarity to other common languages.
>


Hi Theodore,

I find the "objective" reasons in this RFC to be greatly exaggerated.

1. "@@Jit" does not require "half as many characters" as "<<Jit>>"; even
for this, which is probably the shortest attribute anyone will ever use,
the saving is less than 30%; for more common attributes which resemble
entire function calls, it will be a tiny proportional saving.

2. You don't actually explain why @@Foo would be any easier to integrate
with nested attributes than <<Foo>>. Is there some parser conflict that
applies to one and not the other?

3. While confusion with generics is possible, I would be interested to hear
from C# programmers how often they confuse [Attribute] for an array index
operation, or any of the other uses of square brackets.

4. Similarly, I've yet to see anyone point to an example of confusion with
shift operators that's not extremely contrived. I could come up with
equally contrived examples where an attribute contained e-mail addresses
and twitter handles, making @@ look confusing.

5. No other language has been put forward using the @@ operator. It more
closely resembles those languages that use a single @, but the <<Foo>>
syntax more closely resembles those languages that use some form of
brackets.

I also find it disingenuous that you refer to the <<Foo>> syntax as "the
shift tokens" throughout, but do not similarly call your proposed syntax
"the double-suppression token". If one is "double-at", then the other is
"double-angle-brackets".


The one convincing *objective* argument I've seen is Jordi's, that @@ would
be easily greppable. Interestingly, that's not true of any of the other
languages listed in the comparison other than Rust's hash-bracket and maybe
C++'s double-bracket, but that doesn't mean we can't do better.

Other than that, I think it really comes down to a matter of taste. Some
people reacted to the <<Foo>> syntax the way they did to the Cats movie
trailer, and may react to this one better. That's fine; we can make a
decision for subjective reasons, but let's be honest and say that.


Regards,
-- 
Rowan Tommins
[IMSoP]

--00000000000042e21c05a7455909--