Hi
On 7/9/25 19:58, Claude Pache wrote:
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.
Full agreement on Claude's entire email, but particularly this part.
Users have expectations from seeing the `readonly` keyword and adding
the `readonly` keyword is an intentional choice by the class author. The
language should not allow making it easy to violate these expectations
(by accident). This is no different from the language making sure for
you that you may only return values of an appropriate type from a
function having a return type. The `readonly` keyword is part of your
public API just like the types are.
Best regards
Tim Düsterhus
