Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124499
Message-ID: <bddba996-3204-4130-af21-ea375eeeaf22@bastelstu.be>
Date: Thu, 18 Jul 2024 21:58:29 +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>
 <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>
 <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>
Content-Language: en-US
In-Reply-To: <CAOWwgp=uwDebrx-=H8yP1Dgwf9ji=v_qagw9aAxbDJcPvCqKNw@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/17/24 20:31, Nicolas Grekas wrote:
> A bit unrelated to the above topic: we've further clarified the RFC by
> addition restrictions to what can be done with lazy proxies. Namely, when
> the factory returns an object from a parent class, we describe that adding
> more on the proxy class would throw, and we also explain why. We also added
> a restriction to prevent a proxy from having an overridden __clone or
> __destruct when the factory returns a parent, and explained why again.

Note that in the RFC you typoed it as '__destructor' ('or' suffix).

> Please let us know if anyone has other concerns.

I've replied regarding the cloning semantics in an earlier email.

Regarding the `reset*()` methods even with the additional examples I 
remain unconvinced that this is not only necessary to work around 
existing design issues in userland libraries. However I guess that we 
will not reach an agreement here and I also do not consider myself the 
target audience of this RFC. I'm just here to find edge cases :-)

Except for the cloning semantics I cannot find any obvious problems with 
the described semantics.

Best regards
Tim Düsterhus