Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108694
MIME-Version: 1.0
References: <CAH5C8xVYFkgyW88332ei8coMOijuynHXg3A2dL50XU4HP5Vpyw@mail.gmail.com>
 <CAKuGYLTsK2h_Yeo1vMju867hhmzyHt+GwoGStcQtiYMi2VB1tg@mail.gmail.com>
In-Reply-To: <CAKuGYLTsK2h_Yeo1vMju867hhmzyHt+GwoGStcQtiYMi2VB1tg@mail.gmail.com>
Date: Thu, 20 Feb 2020 10:06:13 +0100
Message-ID: <CAF+90c9RKf5PUQY0XHf=8QVVMw8jiJ=7eWfY5TTANEYt-a-ZAA@mail.gmail.com>
To: Matthew Brown <matthewmatthew@gmail.com>
Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000074f3cd059efe381a"
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Immutable/final/readonly properties
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000074f3cd059efe381a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 20, 2020 at 1:27 AM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> Someone recently requested something similar for a PHP static analysis to=
ol
> I wrote (https://psalm.dev/r/f75997a263), though that version only allows
> lazy initialisation inside the class in which a given property is declare=
d.
>
> Personally I don't like either approach =E2=80=93 I think per-property ge=
tters and
> setters would be a more appropriate venue for this functionality, somethi=
ng
> like:
>
> property int $s {
>     public get;
>     private set;
> }
>
> This pattern could also be extended to support per-property getter and
> setter methods.
>

While I certainly like the idea of per-property getters/setters, I think
that both of these have their place. This RFC proposes readonly properties,
that can be initialized once, and then never modified again, even within
the same class. Getters/setters only provide the possibility of having
asymmetric visibility: They prevent modifying the property from outside the
class, but it can still be modified inside the class. In that, readonly
properties offer a stronger guarantee.

Of course, that does leave the question of how often you need one or the
other. Maybe just the asymmetric visibility is sufficient for most
practical purposes, in which case it may not be worthwhile to introduce
readonly properties as a separate feature.

Two comments on the specifics of the RFC:

The RFC allows specifying a default value for readonly properties. However,
a property for which a default value has been specified will always have
that value, as it cannot be overwritten in the constructor. If you write
"public readonly int $foo =3D 42", then $object->foo is *always* going to b=
e
42. I'm not sure what that would ever be useful for, and it seems like
something that is bound to be confusing. Maybe it would make more sense to
forbid readonly properties with default values? (That way, the rule that
readonly properties have to be typed falls out naturally as well -- untyped
properties always have a default.)

Regarding the keyword choice, I think you can drop "sealed" from the list,
as it is an established term that affects inheritance, not mutability. Of
the choices you present, "immutable", "readonly" and "writeonce" seem like
the most viable candidates. "writeonce", while the one that is most
technically accurate, is also *unnecessarily* technically accurate and not
intuitive. From the perspective of an API consumer, I think that "readonly"
is the most accurate description of how they are supposed to interact with
the property. The API contract you want to expose is that they can only
read from the property, not write to it. Calling it "writeonce" would be
quite confusing in that context, because the API consumer is never expected
to write to the property. In the majority of cases you will be providing
fully initialized objects, in which case they are indeed readonly for the
consumer -- the details of the write-once property are only relevant in
special cases like ReflectionClass::newObjectWithoutConstructor() for
serialization libraries, or lazy initialization like in Marco's
ProxyManager.

Regards,
Nikita


> On Wed, 19 Feb 2020 at 12:06, M=C3=A1t=C3=A9 Kocsis <kocsismate90@gmail.c=
om> wrote:
>
> > Hi Internals,
> >
> > I'd like to move my RFC forward to the discussion phase:
> > https://wiki.php.net/rfc/write_once_properties
> >
> > In short, I propose to add support for a new property modifier that wou=
ld
> > allow properties to be initialized, but not modified afterwards.
> >
> > Cheers,
> > M=C3=A1t=C3=A9 Kocsis
> >
>

--00000000000074f3cd059efe381a--