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
