Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124497
Message-ID: <658b9367-a231-4d9f-9fa5-8cf493768614@bastelstu.be>
Date: Thu, 18 Jul 2024 21:38:39 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
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>
 <45847b93-02bf-459f-bcd2-81ba35a12c24@bastelstu.be>
 <CAOWwgpnt77-Sybzc3hcnFEui9t8wAv03NAov4xCK9ib_VRZ0JA@mail.gmail.com>
 <46bd4098-2936-4e46-98e9-fe55118325c2@bastelstu.be>
 <CAOWwgpkCy++W1C2t0PnkZ71S8vq1B734ZNPGw2-OHjmrwO3L4A@mail.gmail.com>
 <61ab36bc-b045-452a-84e0-87367d4c680e@bastelstu.be>
 <CAOWwgp=uZH--82CFDMGUBsxiDuajzL_iyoZZk_05X_7bhwfOFw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAOWwgp=uZH--82CFDMGUBsxiDuajzL_iyoZZk_05X_7bhwfOFw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 7/15/24 10:23, Nicolas Grekas wrote:
>> To me this is what the language evolution should do: Enable users to do
>> things that previously needed to be provided by userland libraries,
>> because they were complicated and fragile, not enabling userland
>> libraries to simplify things that they should not need to provide in the
>> first place because the language already provides it.
>>
> 
> That's exactly it: instead of using a third party lib (or in this case
> implementing a poor man's subset of a correct lazy object implementation),
> the engine would enable using a native feature to achieve a fully correct
> behavior in a very simple way. In this case, LazyServiceEntityRepository
> would directly use ReflectionClass::resetAsLazyGhost to make itself lazy,
> so that its consumers get a packaged behavior and don't need to care about
> the topic while consuming the class.
> 

I guess we have to agree to disagree here.

>> Yes, I think it is clearer. Let me try to rephrase this differently to
>> see if my understanding is correct:
>>
>> ---
>>
>> For every property on that exists on the real instance, the property on
>> the proxy instance effectively [1] is replaced by a property hook like
>> the following:
>>
>>       public PropertyType $propertyName {
>>           get {
>>               return $this->realInstance->propertyName;
>>           }
>>           set(PropertyType $value) {
>>               $this->realInstance->propertyName = $value;
>>           }
>>       }
>>
>> And value that is stored in the property will be freed (including
>> calling the destructor if it was the last reference), as if `unset()`
>> was called on the property.
>>
>> [1] No actual property hook will be created and the `realInstance`
>> property does not actually exist, but the semantics behave as if such a
>> hook would be applied.
>>
> 
> Conceptually, you've got it right yes!
> 

Sweet. Unless I've missed anything the bit about the value being unset 
and the destructor implications is missing in the RFC text. It should be 
added. Also the "Properties that are declared on the real instance are 
bound to the proxy instance" bit because slightly misleading with the 
newest change, because the proxy may no longer define additional properties.

May I suggest something along the lines of the following:

The proxy's properties will be bound to the proxy instance, so that 
accessing any of these properties on the proxy forwards the operation to 
the corresponding property on the real instance as if the proxy's 
property was a virtual property. Any value stored within the proxy's 
properties will be unset() and the destructor will be called if the 
proxy held the last reference. This includes properties used with 
ReflectionProperty::skipLazyInitialization() or 
setRawValueWithoutLazyInitialization().

>> Frankly, thinking about this cloning behavior gives me a headache,
>> because it quickly leads to very weird semantics. Consider the following
>> example:
>>
>>        $predefinedObject = new SomeObj();
>>        $initializer = function () use ($predefinedObject) {
>>            return $predefinedObject;
>>        };
>>        $myProxy = $r->newLazyProxy($initializer);
>>        $otherProxy = $r->newLazyProxy($initializer);
>>        $clonedProxy = clone $myProxy;
>>        $r->initialize($myProxy);
>>        $r->initialize($otherProxy);
>>        $r->initialize($clonedProxy);
>>
>> To my understanding both $myProxy and $otherProxy would share the
>> $predefinedObject as the real instance and $clonedProxy would have a
>> clone of the $predefinedObject at the time of the initialization as its
>> real instance?
>>
> 
> Correct. The sharing is not specifically related to cloning. But when
> cloning happens, the expected behavior is well defined: we should have
> separate states.
> 

Yes, it's clear that the should have separate states. The issue I'm 
having here is that the actual cloning does not happen at the time of 
the `clone` operation, but at an arbitrary later point in time and this 
can have some odd consequences for the object lifecycles. Perhaps my 
example was too simplified.

Let me try to expand the example a little.

     class SomeObj { public string $foo = 'A'; public string $dummy; }

     $predefinedObject = new SomeObj();
     $initializer = function () use ($predefinedObject) {
         return $predefinedObject;
     };
     $myProxy = $r->newLazyProxy($initializer);
     $otherProxy = $r->newLazyProxy($initializer);
     $r->getProperty('foo')->skipLazyInitialization($myProxy);
     $clonedProxy = clone $myProxy;
     var_dump($clonedProxy->foo);
     $r->initialize($myProxy);
     $r->initialize($otherProxy);
     $myProxy->foo = 'B';
     $r->initialize($clonedProxy);
     var_dump($clonedProxy->foo);

I would expect that this dumps 'A' both of the times, because at the 
time of cloning the $foo property held the the value 'A'. But my 
understanding is that it returns 'A' at the first time and 'B' at the 
second time, because `$predefinedObject` is cloned at the time of the 
`$r->initialize($clonedProxy);` call.

> 
>> To me this sounds like cloning an uninitialized proxy would need to
>> trigger an initialization to result in semantics that do not violate the
>> principle of least astonishment.
>>
> 
> Forcing an initialization when cloning would be unexpected. E.g. in
> Doctrine, when you clone an uninitialized entity, you don't trigger a
> database roundtrip. Instead, you create a new object that still references
> the original state internally, but under a different object identity. This
> cloning behavior is the one we've had for more than 10 years and I think
> it's also the least astonishing one - at least if we consider this example
> as a real world trial of this principle.
> 

See above.

Best regards
Tim Düsterhus