Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123535
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_93CAE697-BF3F-42B4-8131-085F211A93D8"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
Subject: [PHP-DEV] Default value for readonly properties
Message-ID: <D6054757-A519-4631-BC1F-29B3A33F72A8@gmail.com>
Date: Fri, 7 Jun 2024 11:07:04 +0200
To: php internals <internals@lists.php.net>
From: claude.pache@gmail.com (Claude Pache)


--Apple-Mail=_93CAE697-BF3F-42B4-8131-085F211A93D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

As of today, readonly properties cannot have a default value:

```php
class UltimateQuestion {
    readonly int $answer =3D 42; // Fatal error: Readonly property =
Question::$answer cannot have default value
}
```

The rationale given in the original RFC =
(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, and =
thus not particularly useful. The notion could become more useful in the =
future, if new expressions are allowed as property default values. At =
the same time, depending on how exactly property initialization would =
work in that case, having a default value on a readonly property could =
preclude userland serialization libraries from working, as they would =
not be able to replace the default-constructed object. Whether or not =
this is a concern depends on whether the property is initialized at time =
of object creation, or as an implicit part of the constructor (or =
similar). As these are open questions, the conservative choice is to =
forbid default values until these questions are resolved.

A new fact is that properties will be able to be declared in interface =
since PHP 8.4 (as introduced in the recently accepted property hooks =
RFC). It is true that, for an individual class, a readonly property is =
functionally equivalent to a constant. But my class implements an =
interface (or, before 8.4, follows a non-written protocol), and whether =
that particular implementation choose to always hold the same value for =
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 =
default values.

About the concern given in the original RFC: =E2=80=9Chaving a default =
value on a readonly property could preclude userland serialization =
libraries from working, as they would not be able to replace the =
default-constructed object=E2=80=9D... TBH, as I almost never serialise =
my objects, and even less often customise serialisation, I can only =
guess what the effective issue is. My best guess is that a custom =
`__unserialize()` method would not be able to reinstate the incriminated =
readonly properties, because those would already have been initialised =
with the default value. If this is the case, a solution is to do for =
`__uninitialize()` the same thing that we have done for `__clone()`, =
see: =
https://wiki.php.net/rfc/readonly_amendments#proposal_2readonly_properties=
_can_be_reinitialized_during_cloning

=E2=80=94Claude=

--Apple-Mail=_93CAE697-BF3F-42B4-8131-085F211A93D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;">Hi,<div><br></div><div>As of today, readonly =
properties cannot have a default =
value:</div><div><br></div><div>```php</div><div><div>class =
UltimateQuestion {</div><div>&nbsp; &nbsp; readonly int $answer =3D 42; =
//&nbsp;Fatal error: Readonly property Question::$answer cannot have =
default =
value</div><div>}</div></div><div>```</div><div><br></div><div>The =
rationale given in the original RFC (<a =
href=3D"https://wiki.php.net/rfc/readonly_properties_v2">https://wiki.php.=
net/rfc/readonly_properties_v2</a>) was:</div><div><br></div><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div>As the =
default value counts as an initializing assignment, a readonly property =
with a default value is essentially the same as a constant, and thus not =
particularly useful. The notion could become more useful in the future, =
if new expressions are allowed as property default values. At the same =
time, depending on how exactly property initialization would work in =
that case, having a default value on a readonly property could preclude =
userland serialization libraries from working, as they would not be able =
to replace the default-constructed object. Whether or not this is a =
concern depends on whether the property is initialized at time of object =
creation, or as an implicit part of the constructor (or similar). As =
these are open questions, the conservative choice is to forbid default =
values until these questions are =
resolved.</div><div><br></div></blockquote>A new fact is that properties =
will be able to be declared in interface since PHP 8.4 (as introduced in =
the recently accepted property hooks RFC). It is true that, for an =
individual class, a readonly property is functionally equivalent to a =
constant. But my class implements an interface (or, before 8.4, follows =
a non-written protocol), and whether that particular implementation =
choose to always hold the same value for a specific property is =
irrelevant.<div><br></div><div><br></div><div><div>```php</div><div>interf=
ace Question {</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>public int $answer { get; =
}</div><div>}</div><div><div>class UltimateQuestion implements Question =
{</div><div>&nbsp; &nbsp; readonly int $answer =3D =
42;</div><div>}</div></div><div>```</div></div><div><br></div><div>Therefo=
re I think it is reasonable for readonly properties to accept default =
values.</div><div><br></div><div>About the concern given in the original =
RFC: =E2=80=9Chaving a default value on a readonly property could =
preclude userland serialization libraries from working, as they would =
not be able to replace the default-constructed object=E2=80=9D... TBH, =
as I almost never serialise my objects, and even less often customise =
serialisation, I can only guess what the effective issue is. My best =
guess is that a custom `__unserialize()` method would not be able to =
reinstate the incriminated readonly properties, because those would =
already have been initialised with the default value. If this is the =
case, a solution is to do for `__uninitialize()` the same thing that we =
have done for `__clone()`, see: <a =
href=3D"https://wiki.php.net/rfc/readonly_amendments#proposal_2readonly_pr=
operties_can_be_reinitialized_during_cloning">https://wiki.php.net/rfc/rea=
donly_amendments#proposal_2readonly_properties_can_be_reinitialized_during=
_cloning</a></div><div><br></div><div>=E2=80=94Claude</div></body></html>=

--Apple-Mail=_93CAE697-BF3F-42B4-8131-085F211A93D8--