Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123537
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-497-g97f96844c-fm-20240526.001-g97f96844
Precedence: bulk
MIME-Version: 1.0
Message-ID: <9c53585a-7898-4406-87ba-8b2055c14904@app.fastmail.com>
In-Reply-To: <D6054757-A519-4631-BC1F-29B3A33F72A8@gmail.com>
References: <D6054757-A519-4631-BC1F-29B3A33F72A8@gmail.com>
Date: Fri, 07 Jun 2024 13:10:53 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] Default value for readonly properties
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jun 7, 2024, at 9:07 AM, Claude Pache wrote:
> Hi,
>
> As of today, readonly properties cannot have a default value:
>
> ```php
> class UltimateQuestion {
>     readonly int $answer =3D 42; // Fatal error: Readonly property=20
> Question::$answer cannot have default value
> }
> ```
>
> The rationale given in the original RFC=20
> (https://wiki.php.net/rfc/readonly_properties_v2) was:
>
>> As the default value counts as an initializing assignment, a readonly=
 property with a default value is essentially the same as a constant, an=
d thus not particularly useful. The notion could become more useful in t=
he future, if new expressions are allowed as property default values. At=
 the same time, depending on how exactly property initialization would w=
ork in that case, having a default value on a readonly property could pr=
eclude userland serialization libraries from working, as they would not =
be able to replace the default-constructed object. Whether or not this i=
s a concern depends on whether the property is initialized at time of ob=
ject creation, or as an implicit part of the constructor (or similar). A=
s these are open questions, the conservative choice is to forbid default=
 values until these questions are resolved.
>>=20
> A new fact is that properties will be able to be declared in interface=20
> since PHP 8.4 (as introduced in the recently accepted property hooks=20
> RFC). It is true that, for an individual class, a readonly property is=20
> functionally equivalent to a constant. But my class implements an=20
> interface (or, before 8.4, follows a non-written protocol), and whethe=
r=20
> that particular implementation choose to always hold the same value fo=
r=20
> a specific property is irrelevant.
>
>
> ```php
> interface Question {
> public int $answer { get; }
> }
> class UltimateQuestion implements Question {
>     readonly int $answer =3D 42;
> }
> ```
>
> Therefore I think it is reasonable for readonly properties to accept=20
> default values.
>
> About the concern given in the original RFC: =E2=80=9Chaving a default=
 value on=20
> a readonly property could preclude userland serialization libraries=20
> from working, as they would not be able to replace the=20
> default-constructed object=E2=80=9D... TBH, as I almost never serialis=
e my=20
> objects, and even less often customise serialisation, I can only guess=20
> what the effective issue is. My best guess is that a custom=20
> `__unserialize()` method would not be able to reinstate the=20
> incriminated readonly properties, because those would already have bee=
n=20
> initialised with the default value. If this is the case, a solution is=20
> to do for `__uninitialize()` the same thing that we have done for=20
> `__clone()`, see:=20
> https://wiki.php.net/rfc/readonly_amendments#proposal_2readonly_proper=
ties_can_be_reinitialized_during_cloning
>
> =E2=80=94Claude

It's also something I'd have to work around in Serde, and other user-spa=
ce serializers would have to as well.  So it would mean work for seriali=
zers, not all of which use __unserialize().

Also, if aviz passes, a public private(set) property has no such restric=
tion and can serve virtually the same role without any of the limitation=
s of readonly.

Hooks also offer another workaround already:

class UltimateQuestion implements Question {
   public int $answer { get =3D> 42)
}

That would have the same net result (at a very small performance hit for=
 the hook invocation), without any compilation issues.  And it doesn't g=
ive serializers any more work to do than they already will have to do fo=
r hooks and virtual properties.

So while I agree that limitation is annoying, I think there are enough w=
ays around it now and hopefully soon if aviz passes that it's more troub=
le than it's worth to try and address directly.

--Larry Garfield