valhalla-dev Digest, Vol 17, Issue 3

[Thomas W]

Hi Vitaly, people

[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

ArrayList is an *implementation*, java.util.List is a contract. Now the
List contract can be filled by anybody -- ArrayList<int>,
ArrayList<boolean> using a byte-per-cell, BooleanBitList using a
bit-per-cell.

The "contract" you referred to (but referencing the incorrect type) gives
you full flexibility, to have whatever storage & addressing are provided by
the implementation. An "implementation" on the other hand, to be
meaningful, has to actually make some things concrete. In a Collection,
storage is likely to be that.

I am happy for bytewise addressing & cell width (in bytes) to be abstracted
in the service of generic specialization; but you're trying to cross a
really clear boundary, when you change the CPU instructions, storage
addressing etc etc etc to address memory below the "byte" level.

I'm pretty sure you can see there's a boundary, too -- Good design is about
choosing the right boundaries & respecting them, such that a useful,
meaningful & efficient abstraction is presented at the higher level.

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

Another abstraction?  Classes have existed since Java 1.0, hardly new. We
should use them, they work well for things such as types providing
different implementations of an interface.

And to correct your second sentence:  there's no capability/semantic
change, it's still a *List*. But there would be _fundamental difference in
implementation_, so it should be a different concrete type.

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

The purpose of a concrete Collection implementation is to implement
storage. 'List' keeps storage out of the type. ArrayList, LinkedList & the
putative BooleanBitList implement it.

It's probably mistaken to claim that implementation is "just a detail" that
can (or should be) abstracted out of the type system. The fundamental
purpose of concrete classes is to organize _concrete code which does
something_, aka implementation, since without implementation a system does
nothing.

Yes, a preprocessor can do "anything". Is it a good idea? No.


Regards,
Thomas