valhalla-dev Digest, Vol 17, Issue 3
twhitmore.nz at gmail.com
Sat Dec 19 06:04:53 UTC 2015
If Optional<T> is the goal, perhaps the question might be to inline/
specialize the storage of monadic/ "wrapper types" generally?
There are probably a range of monadic/ wrapper types having one "major
field" and decorated it with simple behavior. However relying on handcoding
magic specializations in ArrayList, will restrict it to applying to
An alternative way of looking at this is to to designate Optional as
"inline value" which then would enable a _generalized system_ to
arbitrarily reorganize its storage and store/materialize it as necessary.
While stored it would not be in standard representation and inlined
accessors would be adapted to the inline storage representation.
> The biggest advantage to doing this via specialization is that if you do
come up with a better way to represent a generic type
> with a given type arg, the user of such instantiations doesn't need to
change their code.
I was going to call you on this before -- claiming "flexibility" by having
a very limited number of types specially coded for JDK Collections -- with
the requirement for M * N custom code sections, M being the # of collection
implementations and N being the number of types you specially support -- is
not really very flexible.
You're trading off the need for use-site awareness, for the need for
collection-implementation awareness :)
More information about the valhalla-dev