Re: Containers: The REALLY difficult stuff...

[Mike Griebling <grieblm@trt.allied.com>]

> Don't get me wrong, the discussion has been interesting up to now, but all
> those topics have been "solved in my mind" for some time now. What is
> really scaring the **** out of me design-wise is another problem:
> 
>    How can we separate abstract and concrete structure in a general way?
> 
> Let me give one example of what I mean: Consider a "Set" abstraction. It
> can be defined (informally) as having elementary operations "Insert",
> "Remove", "In" and "Empty", as well as "higher-order" operations "Union",
> "Difference", and so on.
> 
> Now these can of course be implemented in various ways, eg. by using a
> "java.util.Vector" like class, by a linked list, by various trees, etc. The
> problem is how we combine "abstract" behaviour with a "concrete"
> implementation. I would like to be able to do the following:
> 
>    VAR s: Set; l: List;
>    ...
>    BEGIN
>      NEW (s); NEW (l);
>      s.UseImplementation (l);
>      ...

Other modular languages such as Ada have this same problem.  They have
all sorts of fancy overloaded operators and generic algorithms whereby
the type can be specified as an instance but they also are not able to
provide a runtime method of switching algorithms.

The general solution is to define a set of modules each for a specific
solution domain.  Using your set example we could have:

1) unbounded set class (perhaps a list implementation)
2) bounded set class (array implementation)

The basic idea is to define the domains to be non-overlapping and abstract
so you don't want multiple implementations of an unbound set class -- you pick
the best and then implement that.  Booch has a complete set of algorithmic
classifications which you might want to investigate for application to
Oberon.  (Sorry I can't recall the exact book title but it was something
like "Object-Oriented Programming with Ada").
 
> So how do we do that? I have that strange feeling that this is next to
> unsolvable with the Oberon-2 context in which we are operating...

See above.

Michael Griebling