Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115209
To: internals@lists.php.net
References: <CAF+90c-W_g9Mt9yMNzBWfMEmQP287a7A6S75RyZo2fvUO2uGXQ@mail.gmail.com>
 <CAF+90c8eE_J-ntY=E8rtusAzh_6mJUKRmYhtunyAV2dPK7LN5Q@mail.gmail.com>
 <CAOWwgpkiMhrQ-zyww8G4aSEcVgKwsr=sagoEZb1r5fszvgOsmA@mail.gmail.com>
 <24af2d01-4f6c-4389-a35a-dab50c0b5e66@www.fastmail.com>
 <CAOWwgp=-QYogyVdpB+2FN858rgyDk3DwoYqGWnhP3D=L9XaS1A@mail.gmail.com>
 <CAOWwgpm5XL5fEDtZbF+Z3hiUSfJ=hacpUr+6-_DJkGL3VAWpDg@mail.gmail.com>
 <CAOWwgpnvX=1f-zzCpOPzu8az3cfiu_vD-Ez0=o8jT=KpfzbHTw@mail.gmail.com>
 <CAF+90c8cth1D3XP32L_MTWBLpMC736b9nq-ds7rHa=P+ydbPJA@mail.gmail.com>
Message-ID: <d8c369c7-af9e-957c-b6be-c01347873d48@processus.org>
Date: Tue, 29 Jun 2021 15:30:15 +0200
MIME-Version: 1.0
In-Reply-To: <CAF+90c8cth1D3XP32L_MTWBLpMC736b9nq-ds7rHa=P+ydbPJA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Subject: Re: [PHP-DEV] Re: [RFC] Readonly properties
From: pierre-php@processus.org (Pierre)

Le 29/06/2021 à 15:08, Nikita Popov a écrit :
> Well, it's a nifty hack :) I don't think this is the solution we want to
> encourage though. It requires you pass extra information through a
> side-channel -- I think I'd rather not use readonly than write that code.
>
> Continuing along the same line, one could extend that to "clone with
> argument" and do something like this:
>
> public function __clone(self $original, array $replacements = []) {
>      foreach ($original as $k => $v) {
>          $this->$k = $replacements[$k] ?? $original->$k;
>      }
> }
>
> and then do "clone $this(['bar' => $bar])".
>
> In any case, I don't want to include changes to cloning in this proposal --
> the topic is related, but also orthogonal to readonly properties.
> Unfortunately, it will not be possible to get cloning changes into PHP 8.1
> anymore, due to feature freeze.
>
> It's okay to vote against this if cloning is a deal breaker. In that case
> I'll probably either work on cloning before re-proposing this, or pivot to
> asymmetric visibility -- it's not my first preference, but it may be the
> more pragmatic choice. Cloning is definitely the weak point of this
> proposal.
>
> Regards,
> Nikita

Hello,

I agree that the "clone with" feature, no matter how the syntax will end 
up being, will become vital as soon as readonly properties will be there 
for many people.

Nevertheless, I also agree with you, both can be done at different 
times, and even if it will block _some_ usages of readonly properties, 
readonly properties as you propose remain a must-have (in my opinion) 
even without the "clone with". I'd be pleased to use them an write 
really immutable objects, even if for cloning I need to do new 
Foo($otherFoo->prop1, $otherFoo->prop2), that's still a huge win in my 
opinion.

I can't vote, but I can't say nothing if people want to block this RFC 
for having the clone with at the same, whereas it could be in a RFC of 
its own, and readonly properties are still a huge feature on its own, 
even without "clone with" support. That's a very wrong reason to say no 
in my opinion: on the contrary, having readonly properties being 
accepted and implemented as-is will be a very persuasive argument in 
favor of the future "clone with" RFC that may emerge following this one.

--

Pierre