valhalla-dev Digest, Vol 17, Issue 3

[Thomas W]

Hi Brian, Vitaly,

Thanks for both your thoughts. I guess you can tell my design preferences
are clearly on the side of KISS.. but we'll put that aside for now, and
consider the question.

My observation would be that "ArrayList<boolean>" has fairly minimal/
uncommon utility..  We're not really discussing language changes for a list
of booleans as the requirement. So I would question whether this whole
discussion, is actually a stalking horse for something else.
- ArrayList<Optional<X>> perhaps?  to me, that seems like the only really
worthwhile candidate.
- are there any others of genuine value?

Vitaly, when we discuss the "contract of ArrayList" today -- or with simple
byte-addressed value type genericization, where the array multiplier  -- we
get a single clear statement of what it does, which I would consider
reasonable to describe as a "contract".

As a thought experiment, let's suppose we give "somebody" this feature of
allowing type-specific overrides, and let them run with it for a while.
- let's say they find the benefits of making ArrayList<boolean> more
compact, as nearly zero value;
- but hey, large objects could be stored off-heap!  that's more valuable
than making dumb old boolean a tiny bit smaller.
--- so they add special support for some perceived large type, to store it
off-heap. it works great.
- but hey, we can store more if we go to disk.
--- so they add file storage as well. there's a few dependencies &
interactions, but come on, it works great.
- that works great. but hey, we're putting Comparables in the list.
shouldn't it be able to sort these automatically?
--- so they add that.. it works great.

All of these features work great! What's the problem?  Problem is, the
design of the class is now rubbish. It doesn't do one thing well any more,
it does five. Ask what the "contract" is and now it's a meaningless jumble
of special-cases.

OO Principle is to prefer composition to inheritance.  "Inheritance" in the
principle means the embodying of functionality in a single class; for us,
this would be via type-specific templating rather than inheritance.

I for one, find a great deal of value in having simple & well-defined
classes which do their job.
- If I want a different implementation, I instantiate a different class.
- I presume that a very large proportion of the requirement for
List<boolean> are actually aware that they're using a 'boolean' -- and can
instantiate a BooleanBitList specifically, if they actually need/ want to
optimize storage of it.

While it's easy to say that SomeCollection<Optional<X>> has a great case to
support efficiently, I think that -- if we consider type-specific
templating as a general architectural direction -- the place that road
leads to, if pursued more than a very little bit, are questionable.

Which obviously raises uncertainty -- if the architectural approach (when
used other than minimally) leads in a direction we don't want to go, as to
whether it's the right direction.

I think this is an exploratory phase so these are all great questions to
consider.  But I'd like to conclude by asking, what types are the real
drivers for this?


Regards,
Thomas