On Wed, Jul 9, 2025 at 1:50 PM Larry Garfield <la...@garfieldtech.com> wrote: > > On Wed, Jul 9, 2025, at 10:42 AM, Eric Norris wrote: > >> 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. > > Can an init hook reference itself, the way get and set can?
I apologize for being ignorant here, but I'm not sure what you mean by "referencing itself". Do you mean the backing value? No, because the backing value is unset - this is the initialization (and in the case of readonly, this is the "writeonce"). > If there is both an init and set hook, what happens? Is it different if set > reads from itself than if it writes to itself? > > Should combining init and set be forbidden as confusing? I don't have strong feelings here, but I think this is solvable in a way that is consistent and unsurprising. If you set the value, the set hook triggers, if the set hook reads the value, it triggers the init hook, if it's readonly, this might trigger an error since the set hook would try to set it a second time. > Can you have both an init hook and a get hook? What happens then? 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? > I don't know the answer to any of those. We could probably collectively > figure out some answers to that in time, but that's a much larger lift than > either Nick or I have any interest in engaging in at this point, especially > when there is a reasonable solution right in front of us that is trivial to > implement. I guess I don't agree that this is a reasonable solution at the moment. I don't know that I think it's unreasonable, either, but something about it feels wrong to me. I agree with Tim that I think of readonly properties as guaranteeing the immutability of identity. Regarding the caching option suggested elsewhere, the semantics mentioned seem confusing to me. The body is called on subsequent gets, but only the value from the first get is returned? I would expect that would be very confusing to developers. If the body wasn't executed on subsequent invocations that might make more sense to me, but then the get hook essentially is an init hook, and why not call it as such. Also, just to throw the idea out there - maybe start with init hooks *only* for readonly properties? Is there something to this, especially if you consider "readonly" actually "writeonce"? Maybe this plus disallowing set hooks?
