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