Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110412
To: internals <internals@lists.php.net>
References: <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CALKiJKrwUA4Mo4HmHVL6ChaQSidpgS3jmc3fqdbZgnob4gk0zg@mail.gmail.com>
 <BYAPR05MB6535BC6C6D0353AE92B6486DDE890@BYAPR05MB6535.namprd05.prod.outlook.com>
 <a589a9bc-67e8-e427-53ef-30b53525c388@gmail.com>
 <BYAPR05MB6535D02144B77539BC92F5C3DE840@BYAPR05MB6535.namprd05.prod.outlook.com>
Message-ID: <5ebecd58-9f39-72b9-369d-dbb60b80af36@gmail.com>
Date: Sun, 7 Jun 2020 23:32:40 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <BYAPR05MB6535D02144B77539BC92F5C3DE840@BYAPR05MB6535.namprd05.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Shorter attribute syntax
From: rowan.collins@gmail.com (Rowan Tommins)

On 07/06/2020 19:37, Theodore Brown wrote:
>> If `<<Foo( <<Bar>> )>>` means something like `new Foo( new Bar )`, then I
>> can imagine it being useful for `<<Foo( <<Bar, Baz>> )>>` to mean
>> `new Foo( [new Bar, new Baz] )`. That would actually be more convenient than
>> the double-at version, where you'd have to write `@@Foo( [@@Bar, @@Baz] )`
>> or use a constructor with a `...$variadic` parameter.
> In that example there are the same number of characters either way, so
> it's not clear the nested `<<>>` approach would be more convenient.
> And do you think it's a good idea to have an additional syntax for
> creating arrays like that? It seems like it could get confusing.


True, it doesn't make a huge amount of difference.

My thinking was that passing a list of attributes as arguments to 
another would be quite a common case, and would add value to the special 
"nested attributes" syntax, which is otherwise just a weird spelling of 
"new" to work around implementation problems (if indeed it does actually 
work around them).



>> Ultimately, it all comes down to judgement calls - is the
>> double-angle-bracket syntax "too verbose", "too ugly" when nested, etc;
>> and does the double-at syntax make it "better enough".
> Yes, I agree that there's a judgment call to make. Out of curiosity,
> given these shortcomings of the double-angle-bracket syntax, do you
> think there are any objective reasons to prefer it over `@@` (other
> than the theoretical BC break of code like `@@@really_suppress_me()`)?


I'm not convinced there's any objective reasons to be found either way, 
but for the sake of "playing devil's advocate", here are a few that 
could be put forward:


If grouped attributes are added, they're actually slightly less verbose 
than repeating a double-at prefix, once you have enough attributes in 
the set:

Minimum spacing and punctuation requires n+3 chars vs 3n, so a saving 
even with 2 attributes:
<<Foo,Bar>>class Bob{}
vs
@@Foo @@Bar class Bob{}

More realistic spacing is 2n+3 vs 3n, giving a saving only with 4 or more:
<<Foo, Bar, Baz, Quux>>class Bob{}
vs
@@Foo @@Bar @@Baz @@Quuxclass Bob{}


Bracket-based syntaxes, particularly with grouping, are more clearly 
separated from the main code, particularly when used inline. For instance:

$f = @@Something @@AnotherThing function(@@Special @@ReallyInt int $var) {};
vs
$f = <<Something, AnotherThing>> function(<<Special, ReallyInt>> int 
$var) {};


Finally, typing up those examples, it occurs to me that @@ is quite a 
"heavy" symbol - it has a large proportion of black (or whatever colour) 
pixels - and inevitably a rather "fussy" one. I find it draws the eye 
more than the angle-brackets do, which feels unfortunate.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]