Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123536
Precedence: bulk
MIME-Version: 1.0
References: <D6054757-A519-4631-BC1F-29B3A33F72A8@gmail.com>
In-Reply-To: <D6054757-A519-4631-BC1F-29B3A33F72A8@gmail.com>
Date: Fri, 7 Jun 2024 15:46:00 +0300
Message-ID: <CAPyeZ4PkMT0yQwiKkthAov4kHLsJf3oLSCvEixdku7OE+-TZ7Q@mail.gmail.com>
Subject: Re: [PHP-DEV] Default value for readonly properties
To: Claude Pache <claude.pache@gmail.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000031f2cb061a4c2fd5"
From: udaltsov.valentin@gmail.com (Valentin Udaltsov)

--00000000000031f2cb061a4c2fd5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Friday, 7 June 2024=E2=80=AFat 12:11, Claude Pache <claude.pache@gmail.c=
om>
wrote:

> 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 thes=
e
> 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 interfa=
ce
> (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 va=
lue 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 alrea=
dy
> 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_propertie=
s_can_be_reinitialized_during_cloning
>
> =E2=80=94Claude
>

Hi, Claude!

Thank you for bringing up this issue! I agree that the phrase "a readonly
property with a default value is essentially the same as a constant" is not
correct for all cases. For example, I might have a class like this:

```php
final readonly class ObjectCollector
{
    private SplObjectStorage $storage;

    public function __construct()
    {
        $this->storage =3D new SplObjectStorage();
    }

    public function add(object $object): void
    {
        $this->storage->attach($object);
    }
}

(new ObjectCollector())->add(new stdClass());
```

It's a fully working example (https://3v4l.org/dSpQO) where `$storage` can
not be replaced with a constant. And it would be nice if `$storage` could
be initialized without a constructor.

I just looked at some of my PHP >=3D8.1 projects and noticed that I have a
few places where the constructor has no parameters and only exists to
initialize readonly properties with smth like `SplQueue`.
--=20
Valentin Udaltsov

--00000000000031f2cb061a4c2fd5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Friday, 7 June 2024=E2=80=AFat 12:11, =
Claude Pache &lt;<a href=3D"mailto:claude.pache@gmail.com" target=3D"_blank=
">claude.pache@gmail.com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div>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>=
=C2=A0 =C2=A0 readonly int $answer =3D 42; //=C2=A0Fatal error: Readonly pr=
operty 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" target=3D"_blank=
">https://wiki.php.net/rfc/readonly_properties_v2</a>) was:</div><div><br><=
/div><blockquote style=3D"margin:0px 0px 0px 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 th=
us not particularly useful. The notion could become more useful in the futu=
re, if new expressions are allowed as property default values. At the same =
time, depending on how exactly property initialization would work in that c=
ase, 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 i=
mplicit part of the constructor (or similar). As these are open questions, =
the conservative choice is to forbid default values until these questions a=
re 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 t=
he recently accepted property hooks RFC). It is true that, for an individua=
l class, a readonly property is functionally equivalent to a constant. But =
my class implements an interface (or, before 8.4, follows a non-written pro=
tocol), and whether that particular implementation choose to always hold th=
e same value for a specific property is irrelevant.<div><br></div><div><br>=
</div><div><div>```php</div><div>interface Question {</div><div><span style=
=3D"white-space:pre-wrap">	</span>public int $answer { get; }</div><div>}</=
div><div><div>class UltimateQuestion implements Question {</div><div>=C2=A0=
 =C2=A0 readonly int $answer =3D 42;</div><div>}</div></div><div>```</div><=
/div><div><br></div><div>Therefore I think it is reasonable for readonly pr=
operties to accept default values.</div><div><br></div><div>About the conce=
rn 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 customis=
e serialisation, I can only guess what the effective issue is. My best gues=
s 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_2rea=
donly_properties_can_be_reinitialized_during_cloning" target=3D"_blank">htt=
ps://wiki.php.net/rfc/readonly_amendments#proposal_2readonly_properties_can=
_be_reinitialized_during_cloning</a></div><div><br></div><div>=E2=80=94Clau=
de</div></div></blockquote></div><br clear=3D"all"><div>Hi,=C2=A0Claude!<br=
><br>Thank you for bringing up this issue! I agree that the phrase &quot;a =
readonly property with a default value is essentially the same as a constan=
t&quot; is not correct for all cases. For example, I might have a class lik=
e this:<br><br>```php<br>final readonly class ObjectCollector<br>{<br>=C2=
=A0 =C2=A0 private SplObjectStorage $storage;<br><br>=C2=A0 =C2=A0 public f=
unction __construct()<br>=C2=A0 =C2=A0 {<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 $th=
is-&gt;storage =3D new SplObjectStorage();<br>=C2=A0 =C2=A0 }<br><br>=C2=A0=
 =C2=A0 public function add(object $object): void<br>=C2=A0 =C2=A0 {<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 $this-&gt;storage-&gt;attach($object);<br>=C2=A0 =
=C2=A0 }<br>}<br><br>(new ObjectCollector())-&gt;add(new stdClass());<br>``=
`</div><div><br></div><div>It&#39;s a fully working example (<a href=3D"htt=
ps://3v4l.org/dSpQO" target=3D"_blank">https://3v4l.org/dSpQO</a>) where `$=
storage` can not be replaced with a constant. And it would be nice if `$sto=
rage` could be initialized without a constructor.</div><div><br>I just look=
ed at some of my PHP &gt;=3D8.1 projects and noticed that I have a few plac=
es where the constructor has no parameters and only exists to initialize re=
adonly properties with smth like `SplQueue`.</div><span class=3D"gmail_sign=
ature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signature"><div=
 dir=3D"ltr">Valentin Udaltsov<br></div></div></div>

--00000000000031f2cb061a4c2fd5--