Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109104
MIME-Version: 1.0
References: <CAH5C8xVY5SFLBt2jZ9dx93rQC_Xjp4pKZJ+MP=K1TbjyDi9CDA@mail.gmail.com>
 <CAOWwgpmBMB3iPyg+GoL=39u68yUX1ERCs2-csENTJ04PmS4xMA@mail.gmail.com>
In-Reply-To: <CAOWwgpmBMB3iPyg+GoL=39u68yUX1ERCs2-csENTJ04PmS4xMA@mail.gmail.com>
Date: Tue, 17 Mar 2020 15:06:01 +0100
Message-ID: <CAH5C8xW0KBj5qYet=nrMrAz_XNViK-4KyMZMQMkxU5veXXVxFg@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003dd05505a10d7076"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Immutable/final/readonly properties
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000003dd05505a10d7076
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> I don't think these issues can nor should be figured out later on: they
> are low-level conceptual issues IMHO.


I don't agree. Initialization would for example 100% work, I only removed
it from the proposal at the end because
we'll have more freedom to add new language behaviour until we find a much
more useful use-case for default
values of "write-once" properties than what we currently have.

Speaking about cloning: I didn't want to propose a "workaround" in this
proposal (as I wrote in the RFC) because
tackling that problem in the same time would make the RFC much more
complex. And since we can divide the whole
problem into two smaller ones (because you can also create a new instance
instead of cloning), I chose this approach.

I proposed an alternative behavior that removes all the issues. I think it
> needs to be discussed more in-depth:
> https://externals.io/message/108675#108753


I'd like to reiterate my answer then: I think your idea and my proposal
doesn't try to solve the same problem.
My goal is to make sure that a property can't be messed with. No matter the
scope, no matter if it's some exotic
use-case (like calling the constructor twice) or a mistake of the author
herself/himself.

Your idea would however add a property-accessor-like feature:
public readonly $foo =3D> read access from the public scope, write access
from everywhere else
protected readonly $foo =3D> read access from the public and protected
scopes, write access from the private scope

It seems to me that it's basically a convention-over-configuration based
property-accessor variant where one can't give
for example read access to the public scope and write access to only the
private scope.

And I'm saying that you try to solve a different problem because we have
already discussed that property accessors
and "write-once" properties are not closely related to each other:
While "write-once properties" would solve a problem that is currently not
possible to do (immutability of properties),
I consider property accessors to be only a syntactic sugar to separate read
and write access to a property without
using getters and setters - at least it's true for the version you proposed=
.

Of course, not everyone considers property immutability a problem to be
worth to bother about (which I can not relate,
but can totally understand), it's also totally ok not to like the special
rules I added or the implementation itself, but please
don't promote your idea as a better version of "write-once" properties that
removes all its issues - simply because it's not
an answer to the same problem and in turn has other issues.

M=C3=A1t=C3=A9

--0000000000003dd05505a10d7076--