[RFC] Readonly property hooks

> > > Le 8 juil. 2025 à 17:32, Nicolas Grekas <nicolas.grekas+php@gmail.com> a > écrit : > > I read Claude's concern, and I agree with Larry's response: the engine > already allows readonly to be bypassed using __get. The added hook doesn't > make anything more lenient. > > > It is true that readonly could be bypassed by __get(); but this is a > legacy behaviour, and you have to take an explicit step to make it > possible. For those unaware of the awful hack, here is a minimal test case: > > https://3v4l.org/N78An > > where the `unset(...)` is mandatory to make it “work”. > > Are we obligated to sanction shortcomings of legacy concepts in newly > introduced concepts that are supposed to replace them? Or can we do > something better? I’ve outlined in a previous email what I think is a > better design for such situation (namely an `init` hook). > > Also, the fact that __get() is not yet deprecated means that we can still > use the aforementioned hack until/unless we’ve implemented a proper > solution. In the worst case, you can still use a non-readonly hooked > property and document the intended invariants in phpdoc. >

> > If a class is final and uses readonly with either hooks or __get, then > that's the original author's choice. There's no need for extra > engine-assisted strictness in this case. You cannot write such code in a > non-readonly way by mistake, so it has to be by intent. > > > Enforcing as strictly as possible its intended invariants is a good design > for a robust language. Yes, it implies that users cannot (or can hardly) > escape annoying constraints. For example, you can’t extend a final class, > even if you think that you have good reason for it, like constructing a > mock object. >

>> Le 8 juil. 2025 à 17:32, Nicolas Grekas <nicolas.grekas+php@gmail.com> a écrit : >> >> I read Claude's concern, and I agree with Larry's response: the engine already allows readonly to be bypassed using __get. The added hook doesn't make anything more lenient. >> > > It is true that readonly could be bypassed by __get(); but this is a legacy behaviour, and you have to take an explicit step to make it possible. For those unaware of the awful hack, here is a minimal test case: > > https://3v4l.org/N78An > > where the `unset(...)` is mandatory to make it “work”. > > Are we obligated to sanction shortcomings of legacy concepts in newly introduced concepts that are supposed to replace them? Or can we do something better? I’ve outlined in a previous email what I think is a better design for such situation (namely an `init` hook). > > Also, the fact that __get() is not yet deprecated means that we can still use the aforementioned hack until/unless we’ve implemented a proper solution. In the worst case, you can still use a non-readonly hooked property and document the intended invariants in phpdoc. > > >> If a class is final and uses readonly with either hooks or __get, then that's the original author's choice. There's no need for extra engine-assisted strictness in this case. You cannot write such code in a non-readonly way by mistake, so it has to be by intent. >> > > Enforcing as strictly as possible its intended invariants is a good design for a robust language. Yes, it implies that users cannot (or can hardly) escape annoying constraints. For example, you can’t extend a final class, even if you think that you have good reason for it, like constructing a mock object. > > —Claude

>> Le 8 juil. 2025 à 17:32, Nicolas Grekas <nicolas.grekas+php@gmail.com> a écrit : >> >> I read Claude's concern, and I agree with Larry's response: the engine already allows readonly to be bypassed using __get. The added hook doesn't make anything more lenient. >> > > It is true that readonly could be bypassed by __get(); but this is a > legacy behaviour, and you have to take an explicit step to make it > possible. For those unaware of the awful hack, here is a minimal test > case: > > https://3v4l.org/N78An > > where the `unset(...)` is mandatory to make it “work”. > > Are we obligated to sanction shortcomings of legacy concepts in newly > introduced concepts that are supposed to replace them? Or can we do > something better? I’ve outlined in a previous email what I think is a > better design for such situation (namely an `init` hook). > > Also, the fact that __get() is not yet deprecated means that we can > still use the aforementioned hack until/unless we’ve implemented a > proper solution. In the worst case, you can still use a non-readonly > hooked property and document the intended invariants in phpdoc. > > >> If a class is final and uses readonly with either hooks or __get, then that's the original author's choice. There's no need for extra engine-assisted strictness in this case. You cannot write such code in a non-readonly way by mistake, so it has to be by intent. >> > > Enforcing as strictly as possible its intended invariants is a good > design for a robust language. Yes, it implies that users cannot (or can > hardly) escape annoying constraints. For example, you can’t extend a > final class, even if you think that you have good reason for it, like > constructing a mock object. > > —Claude

> Hi > > Am 2025-07-08 17:32, schrieb Nicolas Grekas: >> I also read Tim's argument that new features could be stricter. If one >> wants to be stricter and forbid extra behaviors that could be added by >> either the proposed hooks or __get, then the answer is : make the class >> final. This is the only real way to enforce readonly-ness in PHP. > > Making the class final still would not allow to optimize based on the > fact that the identity of a value stored in a readonly property will not > change after successfully reading from the property once. Whether or not > a property hooked must be considered an implementation detail, since a > main point of the property hooks RFC was that hooks can be added and > removed without breaking compatibility for the user of the API. > >> engine-assisted strictness in this case. You cannot write such code in >> a >> non-readonly way by mistake, so it has to be by intent. > > That is saying "it's impossible to introduce bugs". > >> PS: as I keep repeating, readonly doesn't immutable at all. I know this >> is >> written as such in the original RFC, but the concrete definition and >> implementation of readonly isn't: you can set mutable objects to >> readonly >> properties, and that means even readonly classes/properties are >> mutable, in >> the generic case. > > `readonly` guarantees the immutability of identity. While you can > certainly mutate mutable objects, the identity of the stored object > doesn't change. > > Best regards > Tim Düsterhus

> Personally, I would really like to have `get` hooks on readonly properties. Please consider something like this: > > ```php > readonly class Foo > { > public function __construct( > public Output $style, > public string $some { > get => Output::One === $this->style ? ucfirst($this->some) : strtoupper($this->some); > set => '' !== $value ? $value : throw new \Exception(); > } > ) {} > } > ``` > > Easy-to-digest one-liners. Concerns remain separated. Set takes care of validation, get formats.

> If `get` would not be allowed, we couldn’t do such an obvious thing. For what reason?

> Instead we would need to delegate formatting to the `set` hook which is messy.

> > > On 13.07.25 18:17, Nick wrote: > > > On 13. Jul 2025, at 20:38, Marc Bennewitz <marc@mabe.berlin> wrote: > > Hi Nick, Claude, > > Hey Marc, > > I think it's important to explicitly mark it as "this value will be stored in memory", I mean just silently caching the get hook could quickly lead to unexpected behavior. Like one would expect the value to be changed > > The most here made the argument that "a changing value from a readonly get hook" would be the unexpected behaviour. > That’s why we ended up with the current “alternative implementation 2”. Please see my last answer to Rob for a fair example [1] . > > The current preferred alternative implementation covers both situations... > > If a property is `readonly`: > - you can set once > - on read you always get the same (once computed) value back > > This is exactly the behavior I mean which is somehow unexpected if not marked explicitly as the result could be cached and the property value will never change. > > Not being able to write to something doesn't generally mean reading the value will never change. `get => random_int(0, 100);` > > I don't want to say that the path we want to go with readonly being able to assume the value will never change is wrong but I think it's not clear for the user and can be missed quickly - even with a test as you have to read the property multiple time to notice the difference. > > > If a property is NOT `readonly`: > - you can set often > - on read you always get the fresh (often computed) value back > > I argue that this is a very easy mental model. > I hope that voters agree on “cached may be implied by readonly”, as Claude called it. > > All what I'm saying is that this behavior should be explicit and not applied implicitly on a readonly get hook.

> To have an `init` hook doesn’t solve the get hook issue. > > As far as I understood the init hook it would still disallow readonly+get but allow readonly+init and init would be called once the first time the property gets read and the result would end up in the backing store. > > As a result you get the same behavior as `cached get` with the only difference that you write `init => random_int();` instead of `cached get => random_int();`

> Or did I misunderstand it?

> The cached modifier I would expect to be an attribute applicable to any function which uses another cache store similar to how it's possible in python to memorize function calls which would be a very different feature. > > As earlier answered to Claude [2], I seek to write less code. To introduce a `cached` modifier voids this for no strong reason (please see “mental model” above). > > See above - and `init` is just once more character.

> On Thu, Jul 17, 2025 at 3:31 AM Rob Landers <rob@bottled.codes> wrote: > > > > On Tue, Jul 15, 2025, at 19:27, Nicolas Grekas wrote: > > > > > > > > Le lun. 14 juil. 2025 à 15:41, Larry Garfield <larry@garfieldtech.com> a écrit : > > > > On Sun, Jul 13, 2025, at 6:28 PM, Ilija Tovilo wrote: > > > Hi Nick > > > > > > On Fri, Jul 11, 2025 at 6:31 AM Nick <php@nicksdot.dev> wrote: > > >> > > >>> On 8. Jun 2025, at 11:16, Larry Garfield <larry@garfieldtech.com> wrote: > > >>> > > >>> https://wiki.php.net/rfc/readonly_hooks > > >>> > > >>> To not get this buried in individual answers to others: > > >> > > >> I came up with two alternative implementations which cache the computed `get` hook value. > > >> One leverages separate cache properties, the other writes directly to the backing store. > > >> > > >> Links to the alternative branches can be found in the description of the original PR. > > >> https://github.com/php/php-src/pull/18757 > > > > > > I am not a fan of the caching approach. The implementation draft for > > > this approach [^1] works by storing the assigned value in the property > > > slot, and replacing it with the value returned from get one called for > > > the first time. One of the issues here is that the backing value is > > > observable without calling get. For example: > > > > > > ``` > > > class C { > > > public public(set) readonly string $prop { > > > get => strtoupper($this->prop); > > > } > > > } > > > $c = new C(); > > > $c->prop = 'foo'; > > > var_dump(((array)$c)['prop']); // foo > > > $c->prop; > > > var_dump(((array)$c)['prop']); // FOO > > > ``` > > > > > > Here we can see that the underlying value changes, despite the > > > readonly declaration. This is especially problematic for things like > > > [un]serialize(), where calling serialize() before or after accessing > > > the property will change which underlying value is serialized. Even > > > worse, we don't actually know whether an unserialized property has > > > already called the get hook. > > > > > > ``` > > > class C { > > > public public(set) readonly int $prop { > > > get => $this->prop + 1; > > > } > > > } > > > $c = new C(); > > > $c->prop = 1; > > > $s1 = serialize($c); > > > $c->prop; > > > $s2 = serialize($c); > > > var_dump(unserialize($s1)->prop); // int(2) > > > var_dump(unserialize($s2)->prop); // int(3) > > > ``` > > > > > > Currently, get is always called after unserialize(). There may be > > > similar issues for __clone(). > > > > > > For readable and writable properties, the straight-forward solution is > > > to move the logic to set. > > > > > > ``` > > > class C { > > > public public(set) readonly int $prop { > > > set => $value + 1; > > > } > > > } > > > ``` > > > > > > This is slightly differently, semantically, in that it executes any > > > potential side-effects on write rather than read, which seems > > > reasonable. This also avoids the implicit mutation mentioned > > > previously. At least in these cases, disallowing readonly + get seems > > > reasonable to me. I will say that this doesn't solve all get+set > > > cases. For example, proxies. Hopefully, lazy objects can mostly bridge > > > this gap. > > > > > > Another case is lazy getters. > > > > > > ``` > > > class C { > > > public readonly int $magicNumber { > > > get => expensiveComputation(); > > > } > > > } > > > ``` > > > > > > This does not seem to work in the current implementation: > > > > > >> Fatal error: Hooked virtual properties cannot be declared readonly > > > > > > I presume it would be possible to fix this, e.g. by using readonly as > > > a marker to add a backing value to the property. I'm personally not > > > too fond of making the rules on which properties are backed more > > > complicated, as this is already a common cause for confusion. I also > > > fundamentally don't like that readonly changes whether get is called. > > > Currently, if hooks are present, they are called. This adds more > > > special cases to an already complex feature. > > > > > > To me it seems the primary motivator for this RFC are readonly > > > classes, i.e. to prevent the addition of hooks from breaking readonly > > > classes. However, as lazy-getters are de-facto read-only, given they > > > are only writable from the extremely narrow scope of the hook itself, > > > the modifier doesn't do much. Maybe an easier solution would be to > > > provide an opt-out of readonly. > > > > 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. > > > > 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? > > > > 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. > > > > That would allow conditional set hooks, conditional gets, caching gets (like we already have with ??=), and so on. The mental model is simple and easy to explain/document. The behavior is the same as with methods. But the identity of the stored value would be consistent. > > > > 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. > > > > Would that way of looking at it be acceptable to folks? > > > > > > It does to me: readonly applies to the backed property, then hooks add behavior as see fit. This is especially useful to intercept accesses to said properties. Without readonly hooks, designing an abstract API that uses readonly properties is a risky decision since it blocks any (future) implementation that needs this interception capability. As a forward-thinking author, one currently has two choices: not using readonly properties in abstract APIs, or falling back to using getter/setters. That's a design failure for hooks IMHO. I'm glad this RFC exists to fill this gap. > > > > Nicolas > > > > > > To add to this, as I just mentioned on the Records thread, it would be good to get hooks on readonly objects. With the new clone(), there is no way to rely on validation in constructors. The most robust validation in 8.5 can only be done via set/get hooks, but these hooks are not available on readonly classes. This means that it is remarkably easy to "break" objects that do constructor validation + use public(set) -- or use clone() in inherited objects instead of the parent constructor. In my experience, readonly objects typically only do constructor validation (DRY). > > (shoot, double post, sorry Rob) > > I'm not sure I follow - do you actually need both `set` and `get` > hooks for validation? I would think only `set` hooks would be > necessary, and I don't yet think I've seen an objection to `set` hooks > for `readonly`. >

> 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. >

> On 18. Jul 2025, at 23:48, Eric Norris <eric.t.norris@gmail.com> wrote: > > On Fri, Jul 18, 2025 at 12:01 PM Rob Landers <rob@bottled.codes <mailto: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.

> > > >> Le 19 juil. 2025 à 00:41, Rob Landers <rob@bottled.codes> a écrit : >> >> The original author (Nikita) suggested that there's nothing in the original design that precludes accessors -- and highlights languages where there are both and they are doing just fine more than 5 years later. >> > > Hi Rob, > > It is indeed entirely reasonable to have both readonly properties and hooked properties (aka accessors), and today PHP has indeed both of them (and even asymmetric visibility on top of that, as a separate feature contrarily to C#). But it doesn’t mean that it is reasonable for the *same* property to be *both* readonly and hooked, which is the point that is currently disputed. — What do the other languages allow? Is it possible to define a readonly property with a user-defined getter? (Disclaimer: Even if one of them allows such a thing, I’ll still think that it is a bad idea.) > > —Claude