Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123636
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-515-g87b2bad5a-fm-20240604.001-g87b2bad5
Precedence: bulk
MIME-Version: 1.0
Message-ID: <71981e0f-2293-45cb-b3e4-0b115a52220b@app.fastmail.com>
In-Reply-To: 
 <CAP1Jc10EagLDV5s9zPBz=xqK-eGg_byBe2Twne1Jin28S+zb3w@mail.gmail.com>
References: 
 <CAOWwgpmbq5VRrZQvUXDsKiNK4r6+bFA4VxnjQ_U=h8T9r0o3DA@mail.gmail.com>
 <ab83af79-0669-47dd-a3cb-ab72327ae174@bastelstu.be>
 <CAP1Jc13JWVg99AULgzrGXcoCWJtJZGz+nr_VoyUocw8n5n5sfQ@mail.gmail.com>
 <1118bbcd-a7b4-47bf-bf35-1a36ab4628e1@bastelstu.be>
 <CAP1Jc11vNiazMRL8Y-4NcJhsEkg6kgFNKLymTGfEPYRv114oTA@mail.gmail.com>
 <d9798141-8957-4152-a1ae-f2abcfcc036c@app.fastmail.com>
 <CAP1Jc11R1P_c2vwRrSZ01X4cUBYvLukj9iYEYyqM+Hemriv3pw@mail.gmail.com>
 <b71effbb-e267-44bc-b11c-e6dbf4784a88@app.fastmail.com>
 <CAP1Jc10EagLDV5s9zPBz=xqK-eGg_byBe2Twne1Jin28S+zb3w@mail.gmail.com>
Date: Sun, 16 Jun 2024 09:35:40 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Jun 16, 2024, at 8:46 AM, Arnaud Le Blanc wrote:
> On Sat, Jun 15, 2024 at 7:13=E2=80=AFPM Larry Garfield <larry@garfield=
tech.com> wrote:
>> > In practice I expect there will be two kinds of ghost initializers:
>> > - Those that just call one public method of the object, such as the=
 constructor
>> > - Those that initialize everything with ReflectionProperty::setValu=
e()
>> > as in the Doctrine example in the "About Lazy-Loading strategies"
>> > section
>> I'm still missing an example with ::bind().  Actually, I tried to wri=
te a version of what I think the intent is and couldn't figure out how. =
:-)
>>
>> $init =3D function() use ($c) {
>>   $this->a =3D $c->get(ServiceA::class);
>>   $this->b =3D $c->get(ServiceB::class);
>> }
>>
>> $service =3D new ReflectionLazyObjectFactory(Service::class, $init);
>>
>> // We need to bind $init to $service now, but we can't because $init =
is already registered as the initializer for $service, and binding creat=
es a new closure object, not modifying the existing one.  So, how does t=
his even work?
>
> Oh I see. Yes you will not be able to bind $this in a simple way here,
> but you could bind the scope. This modified example will work:
>
> ```
> $init =3D function($object) use ($c) {
>   $object->a =3D $c->get(ServiceA::class);
>   $object->b =3D $c->get(ServiceB::class);
> }
> $service =3D new ReflectionLazyObjectFactory(Service::class,
> $init->bindTo(null, Service::class));
> ```
>
> If you really want to bind $this you could achieve it in a more convol=
uted way:
>
> ```
> $init =3D function($object) use ($c) {
>   (function () use ($c) {
>     $this->a =3D $c->get(ServiceA::class);
>     $this->b =3D $c->get(ServiceB::class);
>   })->bindTo($object)();
> }
> $service =3D new ReflectionLazyObjectFactory(Service::class, $init);
> ```
>
> This is inconvenient, but the need or use-case is not clear to me.
> Could you describe some use-cases where you would hand-write
> initializers like this? Do you feel that the proposal should provide
> an easier way to change $this and/or the scope?

Primarily I was just reacting to this line:

> However, for more complex use-cases where the initializer wishes to ac=
cess non-public properties, it is required to bind the initializer funct=
ion to the right scope (with Closure::bind()), or to access properties w=
ith ReflectionProperty.=20

And asking "OK, um, how?"  Because what I was coming up with didn't make=
 any sense. :-) =20

It's debatable if the use case of wanting to assign to private propertie=
s in the initializer without using Reflection is common enough to warran=
t more.  I'm not sure at this point.  If we wanted to, I could see an ex=
tra flag that would tell the system to bind the closure to the object be=
fore calling it.  I don't know how common a need that will be, though, s=
o I won't insist it be included.  But I would like to see that line clar=
ified with one of the above examples, because as is, I would expect to b=
e able to bind to the object as I was trying to do and it (obviously) di=
dn't work.

>> and I'm unclear what it would do with the proxy object itself that's =
passed in.
>
> Passing the factory itself as argument could be used to make decisions
> based on the value of some initialized field, or on the class of the
> object, or on its identity. I think Nicolas had a real use-case where
> he detects clones based on the identity of the object:
>
> ```
> $init =3D function ($object) use (&$originalObject) {
>     if ($object !=3D=3D $originalObject) {
>         // we are initializing a clone
>     }
> };
> $originalObject =3D $reflector->newProxyInstance($init);
> ```
>
> This was on ghosts, but I think it's also a valid use-case example for=
 proxies.

Hm, interesting.  Please include this sort of example in the RFC, so we =
know what the use is (and when it won't matter, which seems like it woul=
d be the more common case).

>> >> ReflectionLazyObjectFactory is a terrible name.  Sorry, it is. :-)=
  Especially if it's subclassing ReflectionClass.  If it were its own th=
ing, maybe, but it's still too verbose.  I know you don't want to put mo=
re on the "dumping ground" fo ReflectionClass, but honestly, that feels =
more ergonomic to me.  That way the following are all siblings:
>> >>
>> >> newInstance(...$args)
>> >> newInstanceWithoutConstructor(...$args)
>> >> newGhostInstance($init)
>> >> newProxyInstance($init)
>> >>
>> >> That feels a lot more sensible and ergonomic to me.  isInitialized=
(), initialized(), etc. also feel like they make more sense as methods o=
n ReflectionObject, not as static methods on a random new class.
>> >
>> > Thank you for the suggestion. We will check if this fits the
>> > use-cases. Moving some methods on ReflectionObject may have negative
>> > performance implications as it requires creating a dedicated instan=
ce
>> > for each object. Some use-cases rely on caching the reflectors for
>> > performance.
>> >
>> > Best Regards,
>> > Arnaud
>>
>> I'm not clear why there's a performance difference, but I haven't loo=
ked at the reflection implementation in, well, ever. :-)
>
> What I meant is that creating an instance (not necessarily of
> ReflectionObject, but of any class) is more expensive than just doing
> nothing. The first two loops below would be fine, but the last one
> would be slower. This can make an important difference in a hot path.
>
> ```
> foreach ($objects as $object) {
>     ReflectionLazyObject::isInitialized($object);
> }
>
> $reflector =3D new ReflectionClass(SomeClass::class);
> foreach ($objects as $object) {
>     $reflector->isInitialized($object);
> }
>
> foreach ($objects as $object) {
>     $reflector =3D new ReflectionObject($object);
>     $reflector->isInitialized($object);
> }
> ```

Ah, now I see what you mean.  Interesting.  Including that reasoning in =
the RFC would be good.  Though, I don't know how often I'd be calling is=
Initialized() on a larger set of objects, hot path or no. =20

--Larry Garfield