Hi Marcel,

Might be cool if the JIT or Scorch emitted code that is equivalent to
a quick return, but with a low-level nil-guard in place. Like a
quick-return-if-not-nil primitive code.

Is eager initialization out of the question for you?

If all your instVars were initialized on the first read of one of
them, you could also change the class of the object after the lazy
initialization, and the new class would have quick accessors. For
added fanciness, you could auto-generate the "optimized" class and
such accessors in both classes. Though I am totally not sure whether
it is worth the effort or improves the performance at all (since the
call sites are then polymorphic).

notYetInitialized: sounds strange to me, since you could send the
getter in one place and actually use the answer in a totally different
place (where your MNU happens). You could eager-initialize and return
some special case proxy instead of nil that is bound to the original
receiver and takes care of the lazy initialization when called.

Kind regards,
Jakob

Am Di., 21. Juli 2020 um 10:36 Uhr schrieb Marcel Taeumel
<marcel.taeumel at hpi.de>:
>
> Hi all!
>
> I can choose to initialize an instVar eagerly in #initialize or lazily in its accessor via #ifNil:. Yet, the latter requires me to change that accessor to something not being a quick return.
>
> Could there be a simple way to initialize an instVar on its first read access? Like a #notYetInitialized: callback to the instVar-holding receiver. Instead, we get an MNU on UndefiniedObject ...
>
> (Why? Performance reasons for a little project of mine.)
>
> Best,
> Marcel
>