On Fri, Jul 18, 2025, at 18:48, Eric Norris wrote: > On Fri, Jul 18, 2025 at 12:01 PM Rob Landers <rob@bottled.codes> wrote: > > > > > > > > On Fri, Jul 18, 2025, at 17:25, Tim Düsterhus wrote: > > > > Hi > > > > On 7/14/25 15:38, Larry Garfield wrote: > > > Thanks, Ilija. You expressed my concerns as well. And yes, in practice, > > > readonly classes over-reaching is the main use case; if you're marking > > > individual properties readonly, then just don't mark the one that has a > > > hook on it (use aviz if needed) and there's no issue. > > > > A readonly class is not just a convenience shortcut to mark each > > individual property as readonly. It has important semantics of its own, > > because it forces child classes to also be readonly. And even for final > > classes it communicates to the user that "I won't be adding non-readonly > > properties to the class". > > > > > > Wasn’t that the entire point of readonly classes? Because it was painful to > > write readonly for every property. Then if a property is readonly, the > > inherited property is also readonly, so, by extension: a class extending a > > readonly class is also readonly. > > > > There’s no “communication” here; just logic. > > > > > > Marking a class as readonly must therefore be a deliberate decision, > > since it affects the public API of your class and in turn also user > > expectations. > > > > > > Not really. I can remove the readonly designation and manually mark every > > property as readonly. The behavior of the class doesn’t magically change. > > Or, at least, I hope it doesn’t. > > > > > > > Perhaps we're thinking about this the wrong way, though? So far we've > > > talked as though readonly makes the property write-once. But... what if > > > we think of it as applying to the field, aka the backing value? > > > > I think of readonly from the view of the public API surface of an > > object. The property hooks RFC was very explicit in that property hooks > > are intended to be “transparent to the user” and can be added without > > breaking the public API. In other words: Whether or not a property is > > implemented using a hook should be considered an implementation detail > > and as a user of a class I do not care whether there is a backing value > > or not. > > > > > So readonly doesn't limit calling the get hook, or even the set hook, > > > multiple times. Only writing to the actual value in the object table. > > > That gives the exact same set of guarantees that a getX()/setX() method > > > would give. The methods can be called any number of times, but the > > > stored value can only be written once. > > > > As a user of a class the "backing table" is mostly inaccessible to me > > when interacting with objects. It's only exposed via var_dump() and > > serialize(), the former of which is a debug functionality and the output > > of latter not something I must touch. > > > > > It would not guarantee $foo->bar === $foo->bar in all cases (though that > > > would likely hold in the 99% case in practice), but then, $foo->getBar() > > > === $foo->getBar() has never been guaranteed either. > > > > Properties and methods are something different. For methods there a > > reasonable expectation that *behavior* is associated with them, for > > properties there is not. > > > > > > Unless I missed something. Hooks are fancy methods? There is nothing > > intrinsic about object properties. There is nothing that says two calls to > > the same property’s getters are going to result in the same values. There > > is asynchronous php, declare ticks, etc. especially in the case of globals, > > there is no guarantee you even have the same object. At the end of the day, > > it is up to the programmer building that system / program to provide those > > guarantees— not the language. > > I do think that, without any additional information, it would be > reasonable to assume that `$foo->bar === $foo->bar`, i.e. there would > not be side-effects until you've called a method or written to the > object in some way. So I share Tim's opinion here, but I do agree that > with hooks available this is not actually a guarantee. You could > certainly have a `$foo->random_value` property and document that it > will be different each time you call it. > > That said, once the programmer has added the readonly designation to a > property, I do think that something says that two calls to the same > property will result in the same values - the readonly designation. I > disagree with the point that it's not up to the language - the > language should provide an affordance for enforcing programmer intent, > and I see no reason to even have a readonly designation if we're going > to make it easily circumventable or otherwise just a "hint". > > It seems that one common counterpoint to the "let's not make it > circumventable" argument is to point out that it's already > circumventable via __get. I agree with Claude that this is not a > justification for making it *easier* to circumvent. I would also like > to note that the original RFC > (https://wiki.php.net/rfc/readonly_properties_v2#unset) seems to allow > this behavior *for the purpose of lazy initialization*. With an `init` > hook, we'd have solved this problem, and could deprecate the `__get` > hack for `readonly` properties / classes. > > Nicolas Grekas said "__get is certainly not legacy; removing it would > break many use cases without proper alternatives.", but note that I'm > only suggesting we could maybe deprecate __get for `readonly` > properties once we had an `init` hook - I'm not proposing deprecating > it generally. Without a counterexample, I don't think there would be > another reason for `__get` to work with `readonly` properties. >
I personally feel that making special restrictions and affordances to readonly classes is a bad language design. It is a “class” and not something special or different like an enum. This is just a class with its properties made readonly. The word says it all — read. Only. Personally, I don’t use readonly much any more. The amount of restrictions and weird behavior just makes it impossible for any real-world use except for narrow cases the original authors of the feature dreamed up. With hooks and asymmetrical viz, it’s nearly an obsolete feature anyway. — Rob
