Re: [RFC] Readonly property hooks

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