Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114735
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 11:53:47 +0200
Message-ID: <CADK1yXLppzVWpfMWEnT0ggF1X82Gcha2p-8wBb_F9yUNB71UnQ@mail.gmail.com>
To: Pierre <pierre-php@processus.org>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000008681da05c401c99c"
Subject: Re: [PHP-DEV] [RFC] Readonly properties
From: deleugyn@gmail.com (Deleu)

--0000000000008681da05c401c99c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 5, 2021, 11:47 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.net/rfc/readonly_properties_v2
> >
> > This proposal is similar to the
> > https://wiki.php.net/rfc/write_once_properties RFC that has been
> declined
> > previously. One significant difference is that the new RFC limits the
> scope
> > of initializing assignments. I think a key mistake of the previous RFC
> was
> > the confusing "write-once" framing, which is both technically correct a=
nd
> > quite irrelevant.
> >
> > Please see the rationale section (
> > https://wiki.php.net/rfc/readonly_properties_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'))->newInstanceWithoutConstructor();
>
>
> (\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,
> but some hydration libraries such as ocramius/generated-hydrator do
> leverage this mechanism to hydrate objects, and I sometime do it myself
> in business code, sporadically, to hydrate objects from database without
> needing to define a constructor for those value objects.
>
> If it does prevent such code, will there be some additional mechanism to
> create value objects with readonly properties without constructor ? Such
> as an JavaScript object-like object instanciation mechanism ?
>
> <?php
>
> class SomeClass
> {
>      public readonly int $foo;
> }
>
> $bar =3D 12;
>
> $object =3D {
>      foo: $bar,
> };
>
> ?>
>
> I know this goes far outside of this RFC's own scope, but maybe this is
> the occasion to open a discussion about this, this would play well with
> readonly properties and various serializers or hydrators libraries.
>
> Regards,
>
> --
>
> Pierre
>


Sounds like a revelant subject to be raised, indeed. But I honestly hope
that this awkward hack will not prevent us from getting read-only
attributes.

>

--0000000000008681da05c401c99c--