Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124437
Message-ID: <9191a6b3-91f6-4339-99b5-42913bebdaac@bastelstu.be>
Date: Mon, 15 Jul 2024 22:08:42 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Lazy Objects
To: Nicolas Grekas <nicolas.grekas+php@gmail.com>,
 =?UTF-8?Q?Benjamin_Au=C3=9Fenhofer?= <kontakt@beberlei.de>
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>
 <CAEPJduk6m1gdPOrsXYbsc+RLuHeEBav3pGwQO+PHs4UGGqtzhg@mail.gmail.com>
 <CAOWwgp=jdtXk+u_zgQgCfxoc6yXUOwtz6ebQBiNkzSSQ8u7kTQ@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAOWwgp=jdtXk+u_zgQgCfxoc6yXUOwtz6ebQBiNkzSSQ8u7kTQ@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 11:59, Nicolas Grekas wrote:
> With refactoring, we can fix all design issues in all softwares. Yet that's
> too theoretical and this is missing the point IMHO. What we want to provide
> is a complete coverage of the lazy object domain. Simplifying too much can
> lead to an incomplete solution that'd be too restrictive.

I disagree that the right solution to avoiding refactoring in a PHP 
library is pushing the effort upstream into the PHP project itself, 
because performing refactoring in PHP is much much harder, due to the 
larger impact of any change.

Yes, you said that providing the `reset*()` methods is only a small 
incremental change over the lazy object functionality in general, but it 
doesn't stop there.

For any bit of API surface we provide, the following needs to happen:
- Documentation pages need to be written.
- Documentation pages need to be translated.
- In case of bug reports, the person triaging the report will need to 
reference the documentation and RFC to find out what the intended 
behavior is.
- In case it actually is a bug, someone will need to fix the bug.
- In case the bug is not fixable due to a bad choice made in the design 
phase, either the API needs to stay buggy or a replacement API needs to 
be provided and the old one deprecated.
- Any bugfix needs to be weighted against possible breakage, because 
Hyrum's Law exists.
- Any new RFC will need to take the API and the interactions between the 
RFC topic and the API in question into account (for example if lazy 
objects came first and hooks afterwards, then the hook authors would 
need to think about the interaction with lazy objects).

Any bit of API surface we add to PHP will need to remain stable for the 
next 20+ years, because that's the backwards compatibility expectations 
our users have. These expectations are so strong, that users expect us 
to not even deprecate things (see the bulk deprecation discussion thread).

I want to see strong arguments in favor of the inclusion in PHP itself 
that make it clear that the benefits to the users of PHP outweigh the 
maintenance effort for the next generation of PHP maintainers. This 
feature is a complex feature, because of all the interaction with other 
features (case in point: The number of edge cases I pointed out), thus 
it needs stronger arguments compared to the addition of a new function 
(e.g. the array_find() function in PHP 8.4).

I see these arguments in favor of the inclusion in PHP for the new*() 
methods, I do not see these arguments for the resetAs*() methods.

> I share this angle: figuring out the minimal API to cover the domain.
> 
> Yet I showed reset methods proved useful already (see also my example about
> refreshable fixtures) - not only as "just tools", but more importantly from
> a theoretical aspect as a useful API to cover all situations that userland
> will encounter (and does already). If we don't have them, I know I will
> have to maintain a library that already provides this resetting capability
> because there are valid use cases for them. That'd be a failure to address
> the needs of userland on the topic to me.

Best regards
Tim Düsterhus