Re: [VOTE] Readonly properties
| From: | Nicolas Grekas | Date: | Thu, 01 Jul 2021 14:38:31 +0000 |
| Subject: | Re: [VOTE] Readonly properties | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115257@lists.php.net to get a copy of this message | ||
Le jeu. 1 juil. 2021 à 12:23, Nikita Popov <nikita.ppv@gmail.com> a écrit :
> Hi internals,
>
> I have opened voting on
> https://wiki.php.net/rfc/readonly_properties_v2.
> The vote closes 2021-07-15.
>
> See https://externals.io/message/114729 for the discussion
> thread on this
> proposal. I think a decent tl;dr is that readonly properties as proposed do
> not play well with clone-based withers, so some people believe we should
> either improve cloning first, or introduce asymmetric property visibility
> instead, which does not suffer from this issue.
>
Hi NIkita,
I voted against the proposal because it doesn't work with cloning at all.
Cloning is a critical feature of stateful objects, and we should solve it
the same version that introduces readonly IMHO.
If we figure out that we can't agree on a sensible improved behavior for
cloning, we're going to be in a dead-end with readonly.
I think we are not in a hurry and that we should wait for the RFC that
improves cloning to add readonly.
In another thread, you write:
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.
>
I think this is a strong enough weak point to warrant postponing the
decision. Also, this very statement about asymmetric visibility being more
pragmatic is a string hint that we need time to explore it at the same time
IMHO.
Cheers,
Nicolas