valhalla-dev Digest, Vol 17, Issue 3

[Thomas W]

Hi Vitaly,

[ArrayList<boolean> being perhaps a stalking horse for
> ArrayList<Optional<T>>]
>
> Not sure which is more useful as they're different concepts (contiguous
list of booleans vs optional Ts).

We should be measuring potential design decisions in cost vs benefit, and
doing that requires some reasonable understanding of how application/ and
framework programming will use them.

We shouldn't talk about ArrayList<boolean> as though it were something that
should be done at all costs. So far, I've not hearing much/ or anything
supporting its importance; therefore I don't agree that we can meaningfully
use this as a "would like", "should" or "must have" requirement to drive
design.

I'm suggesting this discussion should either put some flesh on this
strawman or (preferably) move on to some real usecases for storage/ or
other specialization, so we can undertake meaningful cost/ benefit
consideration.



> Monads/ wrappers such as Optional are probably an "obvious" case to
> optimize, since they're at the same cardinality & logical level as the
> underlying data;  but currently add significant instance, indirection,
> wrapping & storage cost.
>
> If we want to go to lengths & consider tackling storage size & efficiency,
> why not tackle it generically at the storage level -- with a system for
> "unpacking" value types into arrays -- rather than by specializing at the
> Collection implementation (eg. ArrayList) level?
>

> By packing you mean storing the elements inline with the enclosing class?
If so, yes I'd like to be able to do that as well.
> Inline/packed arrays would be great for other reasons, but I don't know
if that's Valhalla or Panama or not even on the table entirely.
> Either way, I think it's orthogonal to supporting specialization.

Not a single array inline with the enclosing class -- that would lead to a
variable-size object, which I don't think is wanted.What I'm proposing is
multiple arrays (one per field) with the Value broken into its component
fields and stored that way.

eg.  given class Vector {int x, y, z;}

the Collection (say, ArrayList<T>) would declared "packedarray T[]
elements;"
packedarray would be implemented in the JVM as:
    packedarray <Vector3> {
        int[] elements_x;
        int[] elements_y;
    }


My point is that if we want to target *storage*, we can target it at the
*Array level* -- below the Class.

I question why we're trying to specialize storage at the Class level, at
all?  If we do it in the JVM array implementation -- perhaps by defining a
new 'packedarray' or whatever -- this would obviate a lot of the need for
template-style class specialization.

> Specialization would allow author of the class to provide transparent and
natural (I.e. Use constructor and not factory) specialization for
> the types they know.

I don't agree that different code & behavior within a single named Class
can or should be assumed to be "natural". This changes the core Class
concept, which has been singular throughout the history of Java.

There are issues of quality & meaning, in regard to the whole cohesiveness
and meaningfulness of the Class concept. I would want to see some really
good cost/ benefit to justify this approach.


> If they don't know the type, they can't specialize. If you, as a user,
know more types and how to specialize them then use existing
> specialization facilities

Yes, that's my point -- specialization from such a location is limited,
making it of less value.

I would outline a reasonable conservative approach as follows:
1) "generic/ abstract" specialization from a single code source;
2) comparions/ null checks/ sentinels etc coded in the abstract and
implemented appropriate to the type at specialization time.
3) Factory Methods and distinct implementation classes (eg.
BooleanBitPackedList)
for anything more.

The question would be, what real-world benefits are we looking to gain,
when considering the substantial cost & potential loss of conceptual
integrity associated with template-style specialization?


Regards,
Thomas