Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111621
To: internals@lists.php.net
References: <alpine.DEB.2.23.453.2008041440380.7489@singlemalt.home.derickrethans.nl>
 <CAEPJduk12mo-eizR=K7G9TdaMdk7=C5iq88QWwQ6B_tk02r=2w@mail.gmail.com>
Message-ID: <fda949fa-09bf-dc37-fc90-81967df747bb@seld.be>
Date: Wed, 19 Aug 2020 10:45:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CAEPJduk12mo-eizR=K7G9TdaMdk7=C5iq88QWwQ6B_tk02r=2w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
From: j.boggiano@seld.be (Jordi Boggiano)

Hi,

On 18/08/2020 20:00, Benjamin Eberlei wrote:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> I have updated the RFC one last time with as much of the feedback as
> possible:
>
> - a section about comparing to complexity of type definitions
> - removal of the machine reading section as too narrow and ultimately not
> that important as downstream libraries just have to deal with any of it
> - some more nuances in forward compatibility pro/cons section of #[]
> - smaller corrections and improvements.
>
> I don't think something major is missing now.

Thanks for the updates Benjamin.

Just to mention something here in a bit more depth because it is easy to 
overlook in the RFC if you have looked at it a lot.

In "Potential Future Benefits of Enclosed Delimiter Syntax" there is an 
addition of an example using an attribute for an AOP-style 
before-function callback:

     @:Before(fn ($x) => $x*4)

IMO this is much more readable and self-documenting than a dangling 
lambda like @[fn ($x) => %x*4], as the attribute name hints at what is 
going on, and it provides enclosure with the arg list ().

I hope this will address the worries that the shorter @@/@: syntaxes 
would prevent us from adding some features later based on a lack of end 
delimiter, as it was the only objective technical argument in favor of 
#[]/@[].

Now it's IMO all about what syntax people prefer visually..

Best,
Jordi

-- 

Jordi Boggiano
@seldaek - https://seld.be