Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124587
Message-ID: <a720377b-4f94-43ff-a4ce-1a5ed1d7b9ea@bastelstu.be>
Date: Thu, 25 Jul 2024 16:46:52 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>
Cc: Rob Landers <rob@bottled.codes>, =?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?=
 <kontakt@beberlei.de>, PHP Internals List <internals@lists.php.net>
References: <CAOWwgpmbq5VRrZQvUXDsKiNK4r6+bFA4VxnjQ_U=h8T9r0o3DA@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>
 <CAEPJduk6m1gdPOrsXYbsc+RLuHeEBav3pGwQO+PHs4UGGqtzhg@mail.gmail.com>
 <07e065f2-8f64-4bad-9a98-51f4eaf63ddb@app.fastmail.com>
 <CAOWwgpngQtg2NRW6M6RwgSH+OS1iipewHBmM5c36P2MxQGX78A@mail.gmail.com>
 <2a0a4650-c2c5-4c6d-ad3a-25365b3391b2@bastelstu.be>
 <CAOWwgpm9FLy_SNt7HLtJh5sxtfwjZMMN6pOKioDqsJc+GgD-sA@mail.gmail.com>
 <CAOWwgpnwoPH_rkJreh8v+X8WagzcCJ_puT1RWC0c717GMj5Onw@mail.gmail.com>
 <CAOWwgp=uwDebrx-=H8yP1Dgwf9ji=v_qagw9aAxbDJcPvCqKNw@mail.gmail.com>
 <bddba996-3204-4130-af21-ea375eeeaf22@bastelstu.be>
 <CAOWwgpkrrADHJGBj_=_MQn4XbGSgv3W4MuRHtZj1Tri5xJWiKw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAOWwgpkrrADHJGBj_=_MQn4XbGSgv3W4MuRHtZj1Tri5xJWiKw@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/24/24 17:23, Nicolas Grekas wrote:
> Cloning has kept us busy in the last days and after many brainstorming
> sessions, we've decided to follow your initial proposal : make the clone
> operator trigger the initialization of the original object before cloning
> it.

Thank you. That cloning behavior certainly is much easier to reason about.

> I invite everybody to give the RFC a new read.
> 

I'm seeing there are some more changes and not just to the cloning 
section. I've went through the entire RFC once again and here are my 
(hopefully final) five remarks. They are only about textual 
clarification of some behaviors, I don't have any further semantic concerns.

1. `__destruct()` is still called `__destructor()` in some places.

2. In the "Initialization Triggers" section, it says

> The following special cases do not trigger initialization of a lazy
 > object:
> Cloning, unless __clone() is implemented and accesses a property.
This is no longer true with the latest changes.

3. In the "Proxy objects" initialization section, it says:

> The value of properties used with
> ReflectionProperty::skipLazyInitialization() or 
> setRawValueWithoutLazyInitialization() is discarded.
I assume that the destructors of the values will be called if the 
reference count drops to zero? Then perhaps add "as if unset() was 
called" or "as if null was assigned to them" to make it clear that this 
is a regular reassignment and not some lazy object speciality.

4. In the "Proxy objects" initialization section, it says:

> get_class() or the ::class constant evaluate to the class name of
> the proxy, regardless of the actual instance.
This feels misplaced, because my understanding it that it is not 
something about the initialization, but rather proxy objects in general? 
Perhaps this is best moved to the "Real instance implementation" section 
in the Notes. It should also mention the behavior of the `instanceof` 
operator and also type declarations.

Perhaps some phrasing like the following is best: "The externally 
visible type of a lazy proxy is the type of the proxy object, even if 
the real object is of a parent type. This includes the get_class() 
function, the ::class constant, the instanceof operator and type 
checking in parameter, return and property types."

5. In the explanation of 
"ReflectionClass::markLazyObjectAsInitialized()", it says:

> Its behavior is the same as described for Ghost Objects in the
> Initialization Sequence section, except that the initializer is not
> called.
> 

This means that calling `markLazyObjectAsInitialized()` on a lazy proxy 
turns it into a regular object of the proxy class, as if 
`newInstanceWithoutConstructor()` was used, right?

Best regards
Tim Düsterhus