Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123522
Precedence: bulk
MIME-Version: 1.0
References: <CAOWwgpmbq5VRrZQvUXDsKiNK4r6+bFA4VxnjQ_U=h8T9r0o3DA@mail.gmail.com>
 <ab83af79-0669-47dd-a3cb-ab72327ae174@bastelstu.be> <CAOWwgpnxvv_WD=NMJmHRomNG4Z64Gt9NmDSfVyKjEabL5JRxqQ@mail.gmail.com>
In-Reply-To: <CAOWwgpnxvv_WD=NMJmHRomNG4Z64Gt9NmDSfVyKjEabL5JRxqQ@mail.gmail.com>
Date: Wed, 5 Jun 2024 19:41:20 +0200
Message-ID: <CAPzBOBM6=ZfUfDEw_KkqCzLraLozTZydre2e5M=oV-ccUgXvKw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>, 
	Valentin Udaltsov <udaltsov.valentin@gmail.com>, PHP Internals List <internals@lists.php.net>, 
	Arnaud Le Blanc <arnaud.lb@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Wed, Jun 5, 2024 at 6:58=E2=80=AFPM Nicolas Grekas
<nicolas.grekas+php@gmail.com> wrote:
>
> Hi Tim,
>
> Thanks for the detailed feedback. Arnaud already answered most of your qu=
estions, here is the remaining one:
>
>> On 6/4/24 14:28, Nicolas Grekas wrote:
>> > Please find all the details here:
>> > https://wiki.php.net/rfc/lazy-objects
>> >
>> > We look forward to your thoughts and feedback.
>>
>> I've gave the RFC three or four passes and I'm not quite sure if I
>> follow everything, here's a list of some questions / remarks that came
>> to mind, roughly ordered by the order of things appearing in the RFC.
>>
>> - "been tested successfully on the Doctrine and on the Symfony projects"
>>
>> Is there a PoC patch showcasing how the code would change / be
>> simplified for those pre-existing codebases?
>
>
> Yes!
> See https://github.com/nicolas-grekas/symfony/pull/44 for Symfony. All th=
e complex code is gone \o/
> And if anyone is wondering: No, we're not moving this complexity into the=
 engine. As Arnaud wrote somewhere: Implementation in core is simple compar=
ed to userland as we are at the right level of abstraction. No code gen, no=
 edge cases with relative type hints, visibility, readonly, hooks, etc. We =
get more consistent and transparent behavior as well compared to userland i=
mpl.
>
> For Doctrine, the URL is https://github.com/nicolas-grekas/doctrine-orm/p=
ull/6 for now, with the most important line being the removal of the symfon=
y/var-exporter dependency.
>
> After yours and Valentin's feedback, we're considering an updated API tha=
t would provide the same capabilities but that might be more consensual.
>
> The RFC isn't updated but below is what we have in our drafts. Let me kno=
w what you think already if you want (otherwise, let us work on the updated=
 implementation/RFC and we'll let you know about them ASAP).
>
> Nicolas
> PS: I understand that the concepts in the RFC might be difficult to grasp=
. They were certainly challenging for me to summarize. I would happily acce=
pt any help to improve the wording if anyone is willing.
>
>
> class ReflectionLazyClass extends ReflectionClass
> {
> public int const SKIP_INITIALIZATION_ON_SERIALIZE =3D 1;
> public int const SKIP_DESTRUCTOR =3D 2;
>
> public function __construct(object|string $objectOrClass);
>
> public function newLazyGhostInstance(callable $initializer, int $options =
=3D 0): object;
> public function newLazyProxyInstance(callable $initializer, int $options =
=3D 0): object;
>
> public function makeInstanceLazyGhost(object $object, callable $initializ=
er, int $options =3D 0): void;
> public function makeInstanceLazyProxy(object $object, callable $initializ=
er, int $options =3D 0): void;
> public static function isInitialized(object $instance): bool;
> /**
> * Initializes a lazy object (no-op if the object is already initialized.)
> *
> * The backing object is returned, which can be another instance than the =
lazy object when the virtual strategy is used.
> */
> public function initialize(object $object, bool $skipInitializer =3D fals=
e): object;
> /**
> * Marks a property as *not* triggering initialization when being accessed=
.
> *
> * This method is useful to bypass initialization when setting a property.
> */
> public function skipInitializerForProperty(object $object, string $name, =
string $class =3D null): void;
> /**
> * Sets a property *without* triggering initialization while skipping hook=
s if any.
> */
> public function setRawPropertyValue(object $object, string $name, mixed $=
value, string $class =3D null): void;
> }

For virtual proxies, it would be nice if the instance returned didn't
have to be the same type or child type.

For example, in Durable PHP, I allow accessing remote entities via a
Spying Proxy:

$ctx->signal($id, fn(MyEntity $obj) =3D> $obj->doSomething($x));

In this example, ->signal() generates/loads the proxy which implements
MyEntity with code that captures the value of $x to be forwarded to a
remote instance. It then calls the passed closure and captures the
method + arguments passed.

Most of the complexity is generating the objects themselves to
implement the methods. It would be much simpler to implement magic
methods that can intercept the method calls and not worry about
generating an entire class every time a dev wants to use this
functionality.

In my case, none of the complexity actually goes away since I still
need to generate concrete types of the correct type. That being said,
I don't exactly have millions of users so if I still need to manually
create this, I will. I just thought I'd toss out the idea of not
needing an object of the correct type, just one that can handle the
expected behavior.

Robert Landers
Software Engineer
Utrecht NL