valhalla-dev Digest, Vol 17, Issue 3
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
> 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
> 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
> Clear & simple design principle, no? Otherwise we end up with a C-style
> preprocessor, the ability to conditionally code anything, and the notion
> '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.
More information about the valhalla-dev