Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123526
Message-ID: <f8a1fb76-27c2-466c-82a6-7a139342f066@bastelstu.be>
Date: Wed, 5 Jun 2024 20:48:55 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 Valentin Udaltsov <udaltsov.valentin@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>,
 Arnaud Le Blanc <arnaud.lb@gmail.com>
References: <CAOWwgpmbq5VRrZQvUXDsKiNK4r6+bFA4VxnjQ_U=h8T9r0o3DA@mail.gmail.com>
 <ab83af79-0669-47dd-a3cb-ab72327ae174@bastelstu.be>
 <CAOWwgpnxvv_WD=NMJmHRomNG4Z64Gt9NmDSfVyKjEabL5JRxqQ@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAOWwgpnxvv_WD=NMJmHRomNG4Z64Gt9NmDSfVyKjEabL5JRxqQ@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 6/5/24 17:25, Nicolas Grekas wrote:
> Yes!
> See https://github.com/nicolas-grekas/symfony/pull/44 for Symfony. All the
> complex code is gone \o/
> [...]
> For Doctrine, the URL is
> https://github.com/nicolas-grekas/doctrine-orm/pull/6 for now, with the
> most important line being the removal of the symfony/var-exporter
> dependency.

Thank you, I'll have a look at it when I have the time.

> The RFC isn't updated but below is what we have in our drafts. Let me know
> what you think already if you want (otherwise, let us work on the updated
> implementation/RFC and we'll let you know about them ASAP).

I've already mentioned in the sub-thread with Larry that this is also 
what I had in mind after Arnaud's clarification, so that sounds good to me.

I'll give the RFC another full read once you finished incorporating the 
existing feedback. Doesn't really make sense to give feedback on 
something that still is in-flux and that after all might not exist in 
the updated proposal.

> PS: I understand that the concepts in the RFC might be difficult to grasp.
> They were certainly challenging for me to summarize. I would happily accept
> any help to improve the wording if anyone is willing.

I've already said it in my email to Arnaud: Examples showcasing the 
usage of the API in a (simplified) real-world use case would definitely 
help making the RFC easier to understand.

And for me it is important that any interactions with the existing 
functionality [1] are explicitly spelled out. I'm happier spending the 
time reading an RFC that is five times as long, but clearly defines the 
entire behavior, than reading an RFC that leaves many open questions 
that will end up being "implementation-defined" rather than fully 
thought-through.

Best regards
Tim Düsterhus

[1] e.g. my WeakReference question, instanceof behavior, whether or not 
private properties are accessible in the initializer, readonly, etc.