On Feb 28, 2019, at 2:00 AM, Remi Forax <fo...@univ-mlv.fr> wrote: > > static lazy final is lazy because it shares the same late late binding > semantics as indy and condy, i.e it uses the CAS of condy so it doesn't need > a specific CAS from T.default.
> I think that trying to come that will encompass lazy instance field and lazy > static field is a trap, because in the lazy instance case there is no > constant pool to store the value. Hmm… smells like cheese! Let's go look. :-).~ In this case it's more than a trap; the trap can be turned around to become an opportunity. > Given that we already have condy, i prefer to see the lazy static field as a > way to provide a symbolic name to get the condy value from outside the class > that store the condy. Sure we already have condy, and that should provide (a) an easy extension of the current spec. to cover linkage of these guys, and (b) a good implementation. Looking at the language and user experiences, we see the cheese in the trap: "Hey, why do those fields have to be static? What if I want a non-static one? In fact, I'm in the mood to refactor my code to get rid of statics." What I'm proposing is not to back away from the condy semantics for lazy-statics, but rather add a strategic "tweak" to them so that non-statics can be lazy too. In short: If the BSM returns T.default, don't accept it; throw BSME. At the cost of excluding one point from the value space from a lazy variable of type T, we gain a wider range of efficient implementation choices for JVMs. The excluded point is almost always `null`, which is a second-class value already; we are putting it to work in its usual supporting role as a sentinel value. The excluded point can serve as a sentinel for reflection, too; a Field::getUnresolved call can return the sentinel if the lazy field is not yet resolved. This tweak is very simple. It may irritate us a little, but will pave the way for a comfortable story that extends laziness to non-statics also. — John
