[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 mailto:nicolas.grekas%2Bphp@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

https://wiki.php.net/rfc/records

I’ll probably return back to it after 8.5 is released. Knowing what I know today, there are a lot of things id remove.

— Rob

Le 9 juil. 2025 à 15:17, Nick php@nicksdot.dev a écrit :

Hey 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?

Yes, it’s mostly theoretical, but it is good to base language design on sound theory.

But here is a potential practical issue. A random user wants to extend a class from a third-party library, but they are annoyed that a given property is readonly. Now, using a get hook, it is trivial for them to cheat and to work around what it perceives as an undue limitation, not realising that it may break assumptions made elsewhere in the library. — Indeed, I don’t trust users and want to protect them against themselves.

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?

I think indeed that it is not worth making the current proposal more complex, but rather considering whether implementing an init hook instead is a reasonable alternative.

Also there is another issue with the use of get hook for lazy initialisation (although not specific to readonly): The ??= pattern breaks if the property is nullable and you initialise it to null. It is in fact cumbersome to distinguish between an uninitialised property and a property initialised with null.

—Claude

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

I'm not entirely sure I follow - it sounds like your email states that
readonly should be interpreted as writeonce, which makes sense,
but then why would an init hook not be the appropriate answer here?

The two scenarios you listed (set hooks for validation and lazy
computed properties) seem like they could be solved by allowing set
hooks (everyone seems +1 to that), an init hook, and disallowing
get hooks. It would sidestep the controversial nature of a get
hook for the property.

It feels to me like an init hook would be the more conservative
approach, and would (I imagine) still allow for potential readonly
engine optimizations like Tim pointed out. Once we allow get hooks,
there's no going back. If we still needed to add get hooks in the
future, it's not off the table.

I don't know that I feel strongly here, but there does seem something
intuitively off with allowing a get hook for a readonly (writeonce)
property.

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

I think that only covers one use-case for getters on readonly classes. Take this example for discussion:

readonly class User {
public int $elapsedTimeSinceCreation { get => time() - $this->createdAt; }
private int $cachedResult;
public int $totalBalance { get => $this->cachedResult ??= 5+10; }
public int $accessLevel { get => getCurrentAccessLevel(); }
public function __construct(public int $createdAt) {}
}

$user = new User(time() - 5);
var_dump($user->elapsedTimeSinceCreation); // 5
var_dump($user->totalBalance); // 15
var_dump($user->accessLevel); // 42

In this example, we have three of the most common ones:

1. Computed Properties (elapsedTimeSinceCreation): these are properties of the object that are relevant to the object in question, but are not static. In this case, you are not writing to the object. It is still "readonly".
2. Memoization (expensiveCalculation): only calculate the property once and only once. This is a performance optimization. It is still "readonly".
3. External State (accessLevel): properties of the object that rely on some external state, which due to architecture or other convienence may not make sense as part of object construction. It is still "readonly".
   You can mix-and-match these to provide your own level of immutability, but memoization is certainly not the only one.

You could make the argument that these should be functions, but I'd posit that these are properties of the user object. In other words, a function to get these values would probably be named getElapsedTimeSinceCreation(), getTotalBalance, or getAccessLevel -- we'd be writing getters anyway.

— Rob

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

Hey Marc, Hey Eric,

A) Init hook

Marc,

Or did I misunderstand it?

Well, I don’t know. Everyone seems to think of init hooks (and their playing together with other hooks) differently.
Some say this, some say that. That’s the exact issue. Want an example?

Eric just agreed with your code example which has a get hook AND init hook.

class Test {
    public int $seek {
        init => random_int(0, 100);   // called once on read if not initialized
        get => $this->seek + 100;
        set => $this->seek = $value + 100;
    }
}

var_dump((new Test())->seek); // number between 100-200 OR 200-300 depending of the set hook be called once with the result of init as well.
Or did I misunderstand it?

I share the same understanding as you, Marc.

But one mail before he answered to Larry:

I think, at least for readonly, you couldn't have an init hook and a
get hook, since the main objection here is to having get hooks on
readonly properties at all. On normal properties, I think that'd be
okay?

So what is it? Get hook cool, or not? And how does an init hook work exactly?
How play all combinations together? And how with readonly?
Why didn’t your example use readonly if we talk about readonly hooks?

I don’t know all that. And that’s why I have proposed what I proposed.

We have a reasonable solution for set/get, without init, right in front of us; and millions of devs could benefit from it the next release.

Eric,
why it wouldn’t be solved by an init hook? Well, because as you said, readonly get hooks would not be allowed in combination with init.
Others apparently have different opinions. So will they, will they not?

I, however, want get/set on readonly properties. And that is what I proposed here.

An init hook is not part of this proposal and I am not planning to take this on.
This RFC, however, would not block anyone from creating their own RFC for init hooks.

B) Less Code

Marc was talking about init, cache modifier and attributes in the same time.
Claude initially wanted a cache modifier on each hook.

I argue that “readonly implicates cached” is very reasonable here.

Many, many opinions. Many, many options. All have their pros, and cons. All can be attacked, and defended. :)

All I want is the below (less code; and no dealing with unrelated things just because I want to add hooks to a readonly class).

// I have a nice readonly class
final readonly class Entry
{
    public function __construct(
        public string $word,
        public string $slug,
    ) {}
}
// I simply want to add a hooked-property to that readonly class
final readonly class Entry
{
    public function __construct(
        public string $word,
        public string $slug,
        public array $terms {
            set(array $value) => array_map(static function (Term|array $term): Term {
                return $term instanceof Term ? $term : new Term(...$term);
            }, $value);
            get => $this->terms; // something, something
        },
    ) {}
}
// but I cannot. I need to:
// - make the class non-readonly,
// - add some readonly here and there,
// - deal with async visibility
// to eventually end up with this
final class Entry // cannot be readonly, annoying
{
    public function __construct(
        public readonly string $word, // annoying readonly
        public readonly string $slug, // annoying readonly
        private(set) array $terms {  // requires visibility
            set(array $value) => array_map(static function (Term|array $term): Term {
                return $term instanceof Term ? $term : new Term(...$term);
            }, $value);
            get => $this->terms;
        },
    ) {}
}

Adding hook to a readonly class really should not be THAT hard and demanding.

And for that, I believe, I provided a solution that is easy to reason about (all details in previous mails), and allows everyone to achieve what they want.

Cheers,
Nick