Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109107
MIME-Version: 1.0
References: <CAH5C8xVY5SFLBt2jZ9dx93rQC_Xjp4pKZJ+MP=K1TbjyDi9CDA@mail.gmail.com>
 <CAOWwgpmBMB3iPyg+GoL=39u68yUX1ERCs2-csENTJ04PmS4xMA@mail.gmail.com> <CAH5C8xW0KBj5qYet=nrMrAz_XNViK-4KyMZMQMkxU5veXXVxFg@mail.gmail.com>
In-Reply-To: <CAH5C8xW0KBj5qYet=nrMrAz_XNViK-4KyMZMQMkxU5veXXVxFg@mail.gmail.com>
Date: Tue, 17 Mar 2020 16:53:16 +0100
Message-ID: <CAOWwgpk6cFEZ_WQopYG+7=AwvuUAg02opWt1bH=tdSqu5vOF1Q@mail.gmail.com>
To: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d6d25505a10eefe5"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Immutable/final/readonly properties
From: nicolas.grekas+php@gmail.com (Nicolas Grekas)

--000000000000d6d25505a10eefe5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> I'd like to reiterate my answer then: I think your idea and my proposal
> doesn't try to solve the same problem.
>

Like you write in the RFC:
> Although actually =E2=80=9Cwrite-once=E2=80=9D properties and property ac=
cessors are
orthogonal to each other, it's arguable whether we still needed
=E2=80=9Cwrite-once=E2=80=9D properties if we had property accessors.

Both proposals relate a lot to each other: it's one or another, both cannot
coexist: there is only one meaning for the "readonly" keyword once it's
bound to some interpretation.

> once a =E2=80=9Cwrite-once=E2=80=9D property is initialized, it can't be =
changed after
cloning
> The solution could be to add support for either object initializers or
property mutation *during* the clone operation

I think this is my biggest issue: it is very common to write immutable VOs
with "withers" on them (see PSR-7).
Thus the RFC doesn't address the currently most common way of writing
immutable VOs I fear.
I would be very interested in having at least a draft of the possibilities
you have in mind because I don't get the suggestion you make in the RFC
right now.
Having a better clue about this might remove at least part of my concerns.

I think this sentence in the RFC sums up the "why" quite nicely:
> The only problem with solely relying on property accessors is that they
can't prevent changes in the private/protected scope (depending on
visibility).

In short, the RFC builds on the idea that preventing changes to
private/protected scope is worth the listed limitations:
> this RFC proposes to disable the property modifier in question for
[untyped properties]
> Another restriction of =E2=80=9Cwrite-once=E2=80=9D properties is that th=
ey can't have a
default value
> =E2=80=9Cwrite-once=E2=80=9D properties must not override regular propert=
ies

While "property accessors-like" would have none of them if I'm not wrong,
and would solve the "withers" use case.

That's where we have a different judgment IIUC: to me, visibility-bound
read-only access provides all the conceptual guarantees we need:
- as class authors: "don't mess up with my state, you, userland";
- and from userland: "I trust you to know how to deal with your internal
state, you, class author".

From a static analysis pov, all would be plain explicit and could be
verified automatically. Not internal-immutability of course.

Note that I'm just arguing that the extra guarantee you look for might not
be worth the downside. If there is a way to provide private-scope
guaranteed immutability without the listed drawbacks, my concerns would
void (thus my request for precisions about cloning.)

Nicolas

PS: the RFC doesn't mention anything about Reflection-based mutability. It
could be worth adding something since we talked about it on the list:
"ReflectionProperty::setReadOnly()"

--000000000000d6d25505a10eefe5--