[RFC] Readonly property hooks

Thanks for your detailed thoughts, Claude. I'd like to offer my perspective
on some of the points you raised.

Le mer. 9 juil. 2025 à 12:53, Claude Pache claude.pache@gmail.com a
écrit :

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.

__get is certainly not legacy; removing it would break many use cases
without proper alternatives.
The behavior after unset() has been promoted to a language feature when
readonly properties were introduced because it helps solve real world use
cases.
I've been asked recently by Gina if those use cases were covered by eg
native lazy proxies. The answer is no, because native lazy proxies cover
only part of the lazy-proxying domain: what remains is proxying by
interface and proxying internal classes, and those require a way to proxy
all property accesses, which is why magic methods are required.

With the argument that __get can be used to implement the
non-readonly-ness, we could also say that hooks are not needed, because
they can be implemented using __get. Yet, language aesthetics are
important, and we welcomed hooks for this reason. Being able to easily
lazy-init thanks to hooks on readonly would be a welcome improvement to me.

That being said, about your init proposal, I think that could work. I'd
just do it a bit differently: instead of introducing a new "init" hook, I'd
prefer having "set" mean "init" for readonly properties. But I know nothing
about the engine on the topic so I can't comment on the feasibility aspect.
I'll leave this to others.

Just a word about using hooks vs __get for lazy-init: the really hard part
when using __get is emulating the public/protected/private visibility
rules. Hooks make this a non-issue. Yet hooks - unfortunately - can't be
used as a generic lazy-init implementation because of their behavior
related to references. That's another topic, but still related, to
reinforce that __get is certainly not legacy.

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.

That's not strictness when the root concept is already filled with
conceptual holes... I'm surprised nobody ever proposed the concept of an
immutable keyword, that'd be like readonly but that'd accept only
also-immutable values. Until this happens, using readonly for that is
a fallacy I'm sorry... To me that invalidates all related arguments.

Nicolas

Hey 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

I hear you, but I still struggle to fully grasp the issue. It’s genuinely hard for me to come up with a real-world example that actually makes sense.
Everything I’ve seen so far, including the RFC example and what I tried myself (I gave it an honest shot), feels either very theoretical or entirely intentional, and thus perfectly logical in its outcome.

In one of your previous mails you brought up an example that requires calling a class method (read: intentionally changing class state), which would result in a non-consistent value being returned when calling the same property more than once. I get it. But what if the user wants exactly that in their readonly class?

That said I did address your concern here (actual RFC PR branch against alternative; PoC):
https://github.com/NickSdot/php-php-src/compare/allow-readonly-hooks...NickSdot:php-php-src:readonly-hooks-strict

Larry and I agree that we don’t want this complexity in the current RFC.
Perhaps this is something for a separate init hook RFC?

Cheers,
Nick

(Sorry for the duplicate. I forgot to CC the list)

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

Here's the core problem right now:

1. readonly bills itself as immutability, but it fundamentally is not. There are at least two loopholes: __get and a mutable object saved to a property. So while it offering immutability guarantees is nice in theory, it's simply not true in practice. readonly has always been misnamed; it should really be writeonce, because that's all it is. (Once again, this is likely the most poorly designed feature we've added in many years.)

2. In 8.4, if a class is marked readonly, you basically forbid it from having any hooks of any kind, even though you absolutely can honor the write-once-ness of the properties while still having hooks. And that applies to child classes, too, because readonly-ness inherits. So adding a single hook means you have to move the readonly to all the other properties individually, which if inheritance is involved you cannot do.

The RFC aims to address point 2 in a way that still respects point 1, but only point 1 as it actually is (write-once), not as we wish it to be (immutability).

In practice, there's 2 scenarios that I see as useful (or problematic in 8.4, that we want to support):

• set hooks for validation, which don't impact writeonce-ness. I think everyone seems on board with that.

• Lazy computed properties. I use these a ton, even for internal caching purposes. 99% of the time I cache them because my objects are practically immutable, and $this->foo ??= whatever is an easy enough pattern. (If they're not cached then it would be a virtual property, which we're not dealing with for now.) As long as you're caching it in that fashion, the write-once-ness still ends up respected.

Honestly, Nick tried to come up with examples yesterday while we were talking that would not fit into one of those two categories, and for every one of them my answer was "if your code is already that badly designed, there's nothing we can do for you." :-)

Ilija and I had discussed making readonly imply cached/lazy/init in the original hooks RFC, but decided against it. Mainly, it becomes very confusing if a property is going to store a value, as there's three different scenarios to consider: There's a short-set hook, the property is mentioned in its own hooks, and then look for readonly. (Would that mean readonly only works on virtual properties?) It makes a feature that's already, in all honesty, at the edge of reasonable complexity more complex.

An init hook would be clearer, certainly, though it also has its own edge cases. Can you set something that has an init hook? What happens if there's both a get and init hook? These probably have answers that could be sorted out, but that's a different question from "why the <censored> does a readonly class forbid me using even rudimentary hooks???"

I'd be open to a follow up RFC for an init hook, though I likely wouldn't write it myself. But that's a different topic than what we're addressing here.

--Larry Garfield

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

Nick previously suggested having the get-hook's first return value cached; it would still be subsequently called, so any side effects would still happen (though I don't know why you'd want side effects), but only the first returned value would ever get returned. Would anyone find that acceptable? (In the typical case, it would be the same as the current $this->foo ??= compute() pattern, just with an extra cache entry.)

--Larry Garfield

Hi

Apologies for the belated reply. I was busy with getting my own
implementation wrapped up and the thread was so active that I had
troubles keeping up.

Personally, I would really like to have get hooks on readonly properties. Please consider something like this:

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.

I respectfully disagree on the "easy-to-digest" part. A 98 character
line containing logic is not easy to digest.

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

In this specific instance the get hook would not violate my
expectations, but this is not true in general.

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

Running formatting for every access is messy. And it's messy to
needlessly use hooks for something that can just be constructor logic.

Since $some is always assigned when running the constructor, this
can just be:

 readonly class Foo {
     public string $some;

     public function __construct(
         public Output $style,
         string $some,
     ) {
         if ($some === '') {
             throw new \Exception();
         }

         $this->some = match ($style) {
             Output::One => ucfirst($some),
             default => strtoupper($some),
         };
     }
 }

Making Foo a plain old data class without any behavior after
construction and with very obvious control flow within the constructor.
This results in both more efficient and easier to reason about code.

Best regards
Tim Düsterhus

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.

I agree with Marc here, not surprisingly.

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();

Agreed. Nick, I am not sure how the init hook doesn't "solve the get
hook issue". As I understand it, the get hook issue is that get hooks
are not allowed on readonly properties. The init hook would be
identical to a "cached get" hook on a readonly property, so why
doesn't it solve the issue?

Or did I misunderstand it?

I share the same understanding as you, Marc.

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.

I was going to respond to this point earlier, but Marc beat me to it.
An "init" hook is one more character than a get hook, is explicit over
a get hook that works differently only for readonly properties, and
is far fewer characters than the explicit "cached" modifier get hook
option.

On top of that, as Claude mentioned an init hook provides the ability
to differentiate between a null property and an uninitialized property

• an init hook would only be called for uninitialized properties, so
  no need for $this->foo ??= "bar".

Le lun. 14 juil. 2025 à 15:41, Larry Garfield larry@garfieldtech.com a écrit :

Hi Nick

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.

It depends... for example, you might have an isValid property which computes whether or not the object is valid, or in the case of lazy properties, detecting an invalid state there. You also might put validation in getters because you're building up the object over several lines, thus it might only be in a partially valid state during construction:

readonly class User {
public public(set) $first_name;
public public(set) $last_name;
public $name { get => implode(' ', [$this->first_name, $this->last_name]) }
}

$user->first_name = "Rob"
echo $user->name; // oops

Or something. In this case, we can rely on the "uninitialized property" exception to be raised if it isn't yet fully valid, but you might want to throw your own exception.

— Rob

Hi

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

Hi

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.

Hey all,

I allow myself to answer in one single mail, instead to all of you individually.

Honestly, I didn’t expect that this RFC will be THAT controversial. 😅
However, I get it. There are good arguments on either side.

I did hope that the “implicit cache” is a decent middle ground, but that also didn’t work out as I thought.

As mentioned earlier, this is my very first RFC. I am at a point where I am a bit overwhelmed.

That said, Larry and I heard you and already decided to offer a split vote to enable us to at least land “set only” in 8.5.
If we didn’t misunderstood it, then y’all agreed on set (only) should be allowed?

This would IMHO already be a huge improvement compared to now; and a low hanging fruit.
Not exactly what I wanted, but it is what it is.
Long story short. We simply don’t have the time to get init sorted before feature freeze.

I offer to follow up with a “readonly init hook” RFC for 8.6 to sort the rest.

I’d appreciate if voters could settle on a yes for “set only” for 8.5.

Wdyt? Would this help to get closer to closing the discussion?

Cheers,
Nick

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

Hey Claude,

From what I've seen in other languages, this combination is fairly common and not inherently poblematic.

• C# allows get hooks with user-defined logic, even in readonly structs.
• Kotlin uses val with a get() body, which is readonly from the consumer's perspective, even though the value is computed.
• TypeScript allows a get-only accessor which acts readonly.
• Swift also allows get-only computed accessors/hooks.

Most languages treat these as an abstraction boundary: allowing you to expose computed state while still guaranteeing external immutability.

This RFC is proposing something similar: the public surface is observably immutable, even if a value is derived. We can already do this today with more boilerplate:

class Foo {
public function __construct(private readonly int $_bar) {}
public int $bar { get => $this->_bar * 2; }
}

The RFC reduces that boilerplate and clarifies intent. In the example above, there is nothing mutable about it. It is "read only" from a public contract point-of-view, we just can't mark it as a readonly class.

As for side-effects or non-determinism, that is a valid concern, but one that applies to any property hook and non-scalar property. A readonly declaration doesn't necessarily encourage or prevent that, it simply declares that the instance state cannot be mutated after construction.

I'd argue the RFC aligns well with the conventions and capabilities of other languages, and builds on what PHP already allows.

— Rob