Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110400
To: internals <internals@lists.php.net>
References: <BYAPR05MB6535959E5CB99B9BE918E561DE880@BYAPR05MB6535.namprd05.prod.outlook.com>
 <CALKiJKrwUA4Mo4HmHVL6ChaQSidpgS3jmc3fqdbZgnob4gk0zg@mail.gmail.com>
 <BYAPR05MB6535BC6C6D0353AE92B6486DDE890@BYAPR05MB6535.namprd05.prod.outlook.com>
Message-ID: <a589a9bc-67e8-e427-53ef-30b53525c388@gmail.com>
Date: Sat, 6 Jun 2020 13:06:03 +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: <BYAPR05MB6535BC6C6D0353AE92B6486DDE890@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)

Hi Theodore,

Firstly, sorry if my previous e-mail came across overly negative, I 
wasn't in the best mood when I wrote it (gestures vaguely at the state 
of the world).


I think this is possibly the best line I've read all week:

> Well, I guess the line between objective and subjective may sometimes
> be a bit subjective. :)

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".

So I'll try not to get into endless back-and-forth on every point, and 
just pick up on a couple of things.



On 04/06/2020 23:20, Theodore Brown wrote:
> Also, grouped attributes would probably have to be special-cased to
> be disallowed in nested attributes, since they don't make sense there.


I'm not entirely clear how they work in current implementations like 
Doctrine's, but I think nested attributes would have to have completely 
different rules anyway, because you don't access them directly through 
reflection in the same way.

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.



> I don't understand how it's disingenuous. The RFC refers to the shift
> tokens as such because that's what they are (`T_SL` and `T_SR`). The
> proposed `@@` syntax uses a new `T_ATTRIBUTE` token. 


The "::" token in the parser is called T_PAAMAYIM_NEKUDOTAYIM, and 
personally I find T_SL and T_SR just as cryptic and irrelevant. The most 
common place I see those token names is when accidentally running code 
with conflict markers like "<<<<<<<<", or when messing up heredoc 
syntax; even if they weren't so abbreviated, my reaction would be "shift 
what now?" I've used bit-shifts maybe twice in the last ten years, so 
it's just not an immediate association to me.

"Disingenuous" was probably too strong a word, but I do think it relates 
to a fundamental difference in viewpoint: to some people, << and >> are 
first and foremost the shift-left and shift-right operators, and so the 
immediate association on seeing them is so obvious it's not worth 
mentioning; to others, they just look like a new kind of brackets.

That association might actually be a good reason to avoid that syntax, 
but if so it should be spelled out, rather than taken as a given.


Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]