Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114736
MIME-Version: 1.0
References: <CAF+90c-W_g9Mt9yMNzBWfMEmQP287a7A6S75RyZo2fvUO2uGXQ@mail.gmail.com>
 <1e900fb5-4fb9-e283-de67-4fb1e035c0c8@processus.org>
In-Reply-To: <1e900fb5-4fb9-e283-de67-4fb1e035c0c8@processus.org>
Date: Sat, 5 Jun 2021 12:06:59 +0200
Message-ID: <CAF+90c9W06K1+bGy3rG-2yuBx5NM87mSRkyoU7t74ovzn=GjSw@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000008365505c401f951"
Subject: Re: [PHP-DEV] [RFC] Readonly properties
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000008365505c401f951
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 5, 2021 at 11:47 AM Pierre <pierre-php@processus.org> wrote:

> Le 04/06/2021 =C3=A0 17:19, Nikita Popov a =C3=A9crit :
>
> Hi internals,
>
> I'd like to open the discussion on readonly properties:https://wiki.php.n=
et/rfc/readonly_properties_v2
>
> This proposal is similar to thehttps://wiki.php.net/rfc/write_once_proper=
ties RFC that has been declined
> previously. One significant difference is that the new RFC limits the sco=
pe
> of initializing assignments. I think a key mistake of the previous RFC wa=
s
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section (https://wiki.php.net/rfc/readonly_prope=
rties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
>
> Regards,
> Nikita
>
>
> Hello,
>
> If I understood it well you count assignments, one note thought after
> re-reading once again, you state:
>
> > This variant is not allowed, as the initializing assignment occurs from=
 outside the class:
>
> Does this mean it'll prevent programmatic object hydration using the
> scope-stealing closure pattern ? Such as:
>
> <?php
>
> class SomeClass
> {
>     public readonly int $foo;
> }
>
> $bar =3D 12;
>
>
> $object =3D (new \ReflectionClass('SomeClass'))->newInstanceWithoutConstr=
uctor();
>
>
> (\Closure::bind(
>     function (SomeClass $object) ($bar
>         $object->foo =3D $bar;
>     },
>     null,
>     SomeClass::class
> ))($object);
>
> ?>
>
> I know this is a weird stuff to do I wouldn't advise to others myself, bu=
t
> some hydration libraries such as ocramius/generated-hydrator do leverage
> this mechanism to hydrate objects, and I sometime do it myself in busines=
s
> code, sporadically, to hydrate objects from database without needing to
> define a constructor for those value objects.
>
Yes, this is supported. What matters is the scope from which the
initialization occurs. If you rebind a closure to the scope of the class,
then you can perform any operations that would be legal inside that class,
including access to private properties and initialization of readonly
properties.

Regards,
Nikita

--00000000000008365505c401f951--