valhalla-dev Digest, Vol 17, Issue 3

Vitaly Davidovich vitalyd at gmail.com
Sat Dec 12 00:46:53 UTC 2015


sent from my phone
On Dec 11, 2015 7:23 PM, "Thomas W" <twhitmore.nz at gmail.com> wrote:
>
> Hi Vitaly,
>
> > I just wanted to quickly ask if there's still a plan to allow
> specialization of storage
> > based on concrete type - think ArrayList<boolean> being a bit vector
> > internally, as an example.  Any current thoughts/plans?
>
> The clear conclusion I came to, was that specialization of storage
belonged
> in a separate class. And that it would be a design error to try and misuse
> genericization/ value-type handling for that different purpose.
>
> If you want a BooleanBitList, create a separate class for it.

But why? I have a generic class ArrayList that satisfies contract of
whomever wants to use it - why define another abstraction just to support
better/more efficient storage for a given *type*? There's no
capability/semantic change here, it's still an ArrayList.

The world today requires that but it's unnecessary; storage is an
implementation detail that shouldn't necessarily "leak" into the type
system.

> Fundamental differences in how storage is addressed == fundamental
> structural change == different class.
>

I don't consider this a fundamental change in this example.  LinkedList is
a fundamental change from ArrayList because it uses dynamic storage whereas
ArrayList is fixed size (until expansion) and has a few other operational
differences.  To me, that is fundamental.  This will be subjective I
suspect.

> Clear & simple design principle, no?  Otherwise we end up with a C-style
> preprocessor, the ability to conditionally code anything, and the notion
of
> 'class' becomes meaningless.

Generic types, by definition, are incomplete until you instantiate them
with a concrete type.  They will be described by whatever contract they
document, but using the most appropriate storage model when actually
knowing the type seems like a good thing, no? Defining a new class
altogether seems wasteful and unnecessary for such cases.

>
> Regards,
> Thomas


More information about the valhalla-dev mailing list