>Hi Marco, > > > >IMO good as-is: can be relaxed later (8.3 or later), if anybody believes > >> it's a show-stopper. > >> > >Readonly classes don't really need to be lazy. > >> > > > >"Break things and move slow" doesn't feel right to me for the language. > > It's a new keyword that you have to opt into. So it's not breaking > anything. It just means you might not be able to use it for your use case > yet. > > (and before you say that third party code might add it, you can just say > you don't support it yet). >
It's not like it wouldn't be supported *yet*. It won't be supported *by design of the language*. Readonly classes introduce a new concept that isn't backed by any language theory I've read about. Of course it doesn't break until you use it, but conceptually, it breaks a universal design pattern: inheritance-based proxy decorators. What I'm asking for is: what is the justification for this limitation? If there is none, we should drop it. Preemptively breaking universal concepts (decoration) by introducing a never-seen concept might be innovation for sure. Or it might be a mistake. E.g. do we know any other language that provides something like readonly classes? How do they deal with inheritance? Can anyone answer those questions? If we come to the conclusion that there is no backing theory to support propagating the readonly flag to child classes, then we might decide if we want to fix this in 8.2 or 8.3. I know I would prefer acting in 8.2, but that's a separate discussion. Nicolas
