Re: List Container Straw Man

["Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org>]

I don't mind underlying complexity if there is any way to hide it. If the
design can be such that you have the complex versions around but through
instantiations or inheritance you can get a simpler version, then great.
(Not sure how you would do that...) The important thing in my mind is that
there are going to be a bunch of potential users who just need to slap
something simple together to hold a bunch of data and they're not going to
want every conceivable option available to them to do that.

I could imagine a design of a component library that would include some kind
of plain vanilla Lists and Maps that let you do the simple things and then
extend it with variants that allow more complex things to occur, such as
inheriting from iterators or controlling storage or whatever. Get something
that covers 80% of the average usage first, then worry about the more arcane
cases later. I don't think that a first cut at a standard component library
should attempt to be the software equivalent of a Swiss Army Knife, covering
every conceivable usage. Just your basic Boy Scout Knife with two or three
blades.

Can you imagine a way to take the classes that Nick suggests and use them as
the basis on which a simple list similar to what Ted suggests is built? That
means you have the underlying power if you want to peel away the layers and
use it, but for the simple cases you've got a nice, simple, instantiation
with nice simple subprogram calls? This might be a way to utilize the BC's.
If Ted, et alia, could be clever enough to hide the complexity under some
other layer, they might be able to overcome the objections and get what they
want. Hmmmmmm..........

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
news:u1yjacqea.fsf@gsfc.nasa.gov...
>
> In a truly complete library, I think both options should be available;
> abstract containers and concrete, simple lists. Perhaps the "Dennison
> List" package could be used to implement the doubly-linked list
> variant of the abstract container package; would that work for you?
>