Le ven. 18 juil. 2025 à 18:32, Tim Düsterhus <t...@bastelstu.be> a écrit :
> Hi
>
> On 7/17/25 18:26, Larry Garfield wrote:
> > Given the lack of consensus both here and in off-list discussions on how
> to handle get hooks, we have done the following:
> >
> > * Split the RFC into two sections, one for get, one for set.
> > * Expanded and refined the examples for both. The implementation is
> still the original, however.
> > * Split the vote into two: one for allowing readonly get hooks, one for
> readonly set hooks.
> >
> > We will start the vote sometime this weekend, most likely, unless some
> major feedback appears before then, and let the chips fall where they may.
>
> After working through (most of) the discussion, I've now taken a look at
> the updated RFC. I have the following remarks:
>
> 1.
>
> > It is really “write-once”, which is not the same as immutable (as shown
> above). But there's no reason that “write-once” need be incompatible with
> hooks.
>
> This is a strawman argumentation, as I've outlined in my previous
> emails, calling readonly "write-once" is wrong. It is a reasonable user
> expectation to always get the identical value when reading a value that
> may only be set once. By calling it "write-once" you are trying to shift
> the focus to the write operation, which is totally irrelevant for user
> expectations when interacting with readonly properties. Especially for
> expectations of users that just *use* a class rather than writing one.
>
To my ears, write-once is more accurate than readonly because it sticks to
the facts of how this behaves. That's very relevant.
Using readonly to suggest immutable is where the arguments for rejecting
this RFC are weak.
readonly doesn't mean immutable, no matter how hard some want it to be...
>
> 2.
>
> > The concern would only appear if someone is deliberately doing something
> non-stable
>
> Or if someone accidentally calls a (deep) function chain that is non-pure.
>
> 3.
>
> > Or, for a more real-world and larger example, PHP 8.4 requires this:
>
> This is false. You are perfectly able to write this in PHP 8.4:
>
> final readonly class Entry
> {
> public readonly $terms;
>
> public function __construct(
> public string $word,
> public string $slug,
> array $terms,
> ) {
> $this->terms = $this->upcastTerms($terms);
> }
>
> private function upcastTerms(array $terms): array
> {
> $upcast = static fn (Term|array $term): Term
> => $term instanceof Term ? $term : new Term(...$term);
> return array_map($upcast, $value)
> }
> }
>
> In no way do you need to use a property hook.
>
> 4.
>
> > // New code in 8.5:
> >
> > $p = new PositivePoint(3, 4);
> > $p2 = clone($p, ['x' => -10]);
>
> This is not legal code in PHP 8.5. Clone-with respects visibility and
> since your asymmetric visibility RFC included the change, you are
> probably aware that `readonly` implies `protected(set)`.
5.
>
> > but are now necessary to ensure that invariants are enforced.
>
> And therefore with PHP 8.5 hooks are not necessary to enforce
> invariants, except in the rare case where a `public(set) readonly`
> property is used.
>
Of course it's rare. It's brand new...
Yet this example comes back many times.
This is how the community would like to use clone-with.
This should be acknowledged.
The fact that protected(set) is (currently) the default is not an argument
to make public(set) a second class citizen.
> 6.
>
> > So no guarantees are softened by this RFC.
>
> Yes, they are. Unless `__get()` is implemented on a class (which is
> explicitly visible as part of the public API), readonly guarantees the
> immutability of identity.
>
Which is not really relevant when talking about immutability.
What everybody is looking for when using that word is immutable objects.
7.
>
> > While that is an interesting idea that has been floated a few times, it
> has enough complexities and edge cases of its own to address that we feel
> it is out of scope.
>
> While it certainly is your right as the RFC authors to consider certain
> things out of scope for an RFC, I strongly oppose the notion of shipping
> something that is strictly inferior and comes with obvious semantic
> issues due to perceived complexity of another solution and then
> following up with the proper solution that has already been identified.
> As I've outlined in my previous emails, I found defining semantics for
> an 'init' hook straight-forward when looking at how PHP works as of today.
>
> 8.
>
> > However, this RFC is in no way incompatible with adding an init hook in
> the future should it be proposed.
>
> This is true, but as I've mentioned before, an 'init' hook would enable
> the same use cases without bringing along issues. So it really should be
> "one of them, but not both" (with "one of them" being the init hook).
>
> --------
>
> After reading through the discussion, it seems the only argument against
> the 'init' hook is perceived complexity. It is not at all clear to me
> why this means that we must now rush something with clear issues into
> PHP 8.5.
>
I'd understand the arguments you're pushing for if readonly were
appropriate to build immutable objects. Yet that's not the case, so such
reasoning is built on sand I'm sorry...
To me the RFC enables useful capabilities that authors are going to need.
Or find workarounds for. Which means more ugliness to come...
Nicolas
