valhalla-dev Digest, Vol 17, Issue 3

[Vitaly Davidovich]

And of course, if you create a new type someone has to know about it to use
it.  If you specialize a generic type, they only need to know about the
generic type.  There's no need to create factories for every single
specialization, whose set is dynamic over time.  Caller code doesn't change
here.

sent from my phone
On Dec 11, 2015 7:46 PM, "Vitaly Davidovich" <vitalyd at gmail.com> wrote:

> 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
>