Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120068
Message-ID: <1b842b25-c038-f647-67e1-b8c986b7d51d@bastelstu.be>
Date: Tue, 18 Apr 2023 18:48:00 +0200
MIME-Version: 1.0
Content-Language: en-US
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <CAH5C8xUn2wotLg0L7KZHoOGf3q-UqbL=47p2PLzK_mOBb=MJXQ@mail.gmail.com>
 <CAAwdEzCuLLd3uc-1Q+PaMW2PkJcg=KoP89vG+NXn5W3o+bvqFw@mail.gmail.com>
 <687944e3-75ec-446b-bbd6-6d3d6856e864@app.fastmail.com>
In-Reply-To: <687944e3-75ec-446b-bbd6-6d3d6856e864@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [Discussion] Clone with
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

Hi

On 4/18/23 17:45, Larry Garfield wrote:
> I agree with the discussion of Nicolas's alternative, which has its merits but also some possible limitations.  My only major concern myself is the potential confusion between when to use : and when to use =>.  Using the => version only for dynamic keys feels very clunky.  In fact, I think the RFC is inconsistent on this front:
> 
> $object = clone $object with {"foo" => 1}; // the property name is a literal
> $object = clone $object with {strtolower("FO") . "o" => 1}; // the property name is an expression
> $object = clone $object with {PROPERTY_NAME => 1}; // the property name is a named constant
> 
> I would expect the first one to be a colon, not fat-arrow.  Is that a typo?

No, that is correct. Colon takes a bare identifier, fat-arrow takes an 
expression (that just happens to be a constant expression in that case).

> Is there a technical reason why they can't just all use a colon?  That would extend more nicely to supporting dynamic keys in the future for named arguments.

I'd rather see only the fat-arrow being allowed. Unless I'm missing 
something, braces with colon is not used anywhere else, whereas braces + 
'=>' is known from match() and '=>' more generally is already used with 
array literals [1]. Having two similar syntaxes for the same thing is 
not great when both are commonly needed is not great. They need to be 
documented and learned by developers.

Best regards
Tim Düsterhus

[1] In fact if the right hand side of with may be an expression that 
evaluates to an array, folks wouldn't need to learn new syntax at all:

     $newProperties = [ "foo" => "bar" ];
     clone $object with $newProperties;

and

     clone $object with [ "foo" => "bar" ];