Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123619
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: <b71effbb-e267-44bc-b11c-e6dbf4784a88@app.fastmail.com>
In-Reply-To: 
 <CAP1Jc11R1P_c2vwRrSZ01X4cUBYvLukj9iYEYyqM+Hemriv3pw@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>
Date: Sat, 15 Jun 2024 12:09:50 -0500
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
Content-Type: text/plain
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jun 15, 2024, at 8:28 AM, Arnaud Le Blanc wrote:
> Hi Larry,
>

>> Under Common Behavior, you have an example of calling the constructor directly, using the reflection API, but not of binding the callable, which the text says is also available.  Please include an example of that so we can evaluate how clumsy (or not) it would be.
>
> I've clarified that binding can be achieved with Closure::bind(). 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::setValue()
> as in the Doctrine example in the "About Lazy-Loading strategies"
> section

I'm still missing an example with ::bind().  Actually, I tried to write a version of what I think the intent is and couldn't figure out how. :-)

$init = function() use ($c) {
  $this->a = $c->get(ServiceA::class);
  $this->b = $c->get(ServiceB::class);
}

$service = 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 creates a new closure object, not modifying the existing one.  So, how does this even work?

> In practice we expect that makeInstanceLazy*() methods will not be
> used on fully initialized objects, and that the flag will be set most
> of the time, but as it is the API is safe by default.

In the case an object does not have a destructor, it won't make a difference either way, correct?

>> I find it interesting that your examples list DICs as a use case for proxies, when I would have expected that to fit ghosts better.  The common pattern, I would think, would be:
>>
>> class Service {
>>     public function __construct(private ServiceA $a, private ServiceB $b) {}
>> }
>>
>> $c = some_container();
>>
>> $init = fn() => $this->__construct($c->get(ServiceA::class), $c->get(ServiceB::class));
>>
>> $service = new ReflectionLazyObjectFactory(Service::class, $init);
>>
>> (Most likely in generated code that can dynamically sort out the container calls to inline.)
>>
>> Am I missing something?
>
> No you are right, but they must fallback to the proxy strategy when
> the user provides a factory.
>
> E.g. this will use the ghost strategy because the DIC
> instantiates/initializes the service itself:
>
> my_service:
>     class: MyClass
>     arguments: [@service_a, @service_b]
>     lazy: true
>
> But this will use the proxy strategy because the DIC doesn't
> instantiate/initialize the service itself:
>
> my_service:
>     class: MyClass
>     arguments: [@service_a, @service_b]
>     factory: [@my_service_factory, createService]
>     lazy: true
>
> The RFC didn't make it clear enough that the example was about the
> factory case specifically.

Ah, got it.  That makes more sense.

Which makes me ask if the $initializer of a proxy should actually be called $factory?  Since that's basically what it's doing, and I'm unclear what it would do with the proxy object itself that's passed in.

>> ReflectionLazyObjectFactory is a terrible name.  Sorry, it is. :-)  Especially if it's subclassing ReflectionClass.  If it were its own thing, maybe, but it's still too verbose.  I know you don't want to put more 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 on 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 instance
> 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 looked at the reflection implementation in, well, ever. :-)

If it has to be a separate object, please don't make it extend ReflectionClass but still give it useful dynamic methods rather than static methods.  Or perhaps even do something like

$ghost = new ReflectionGhostInstance(SomeClass::class, $init);
$proxy  = new ReflectionProxyINstance(SOmeClass::class, $init);

And be done with it.  (I'm just spitballing here.  As I said, I like the feature, I just want to ensure the ergonomics are as good as possible.)

--Larry Garfield