Re: MI - clutching at straws

[eachus@mitre-bedford.arpa (Robert I. Eachus)]

In article <1992Sep15.140840.3405@Urmel.Informatik.RWTH-Aachen.DE> pk@rwthi3.in
formatik.rwth-aachen.de (Peter Klein) writes:

  > Well, either you didn't understand my example or I didn't
  > understand yours... Anyway, if you insist to do so, you could make
  > a class then which is both a set and a tree. But who would want to
  > do so?

    I think we now understand each other very well.  The "easy" case
does not require MI and is uninteresting.  The crazy case is crazy.
The interesting case is interesting, but requires a lot of thought on
the part of the programmer, and while MI might help with the busywork,
it is no substitute of thought where that is needed.

    But, surprise! I realized that there is a specific case whis is
interesting, and in which it happens that I did implement using
generics to do mix-ins.  I needed to implement two dimensional sparse
matrices, (and operations like addition on them).  The solution I
chose was to create a generic list package and instantiate it four
times.  Once to create the row operations, once to create the column
operations, and then once each to create lists of the heads of the
rows and columns.

   When I was finished with the program, I had about four different
layers of generic instantiations, since the list package wasn't the
only generic I used.  But inlining meant that the final product was at
least as fast as totally unmaintainable spaghetti code.  (And somewhat
more maintainable.  That particular program reminds me of Heaviside's
reply when a physicist complained that his papers were hard to read:
"Not nearly as hard as they are to write!")  

  > Hmm, isn't this exactly what I said? I mean, that MI shouldn't be
  > used to combine arbitrary classes. Or what do you mean by "union
  > style MI"?

   For the record, what I mean by union style MI is when neither
parent dominates the other.  This works fine for orthogonal cases, but
falls down when an ordering is needed.  Most MI languages do have a
precedence rule, but when you need to know what it says, you are
already in trouble.

  > Yes and no. It is important to make a distinction between combining
  > arbitrary extensions and extensions which should not be combined. IMHO,
  > it is illegal to state that *if* I want to combine extensions, these
  > possible extensions must be known to the base type. It's a quite
  > natural situation that I want extensions to be mixable, but I cannot
  > predict how many extensions there will be.

   I think you missed my point here.  I said that the person who
defines the extension in Ada 9X chooses whether and how it is mixable.
He does not define which other extentions it can be mixed with just
which meta-class? (I need a word here and all the normal words are
taken) of extentions it will mix with.  Some extensions only extend
members of a specific class hierarchy, others will extend members of
any class, etc.

  > ... The writer of the base class for the nodes doesn't want to
  > know in what way his class will be augmented; i.e. which node
  > classes there will be and what attributes they have. But still,
  > the type designer might want these to be combined.

    Fine.  Getting a little more specific, you may have a graph where
there are various types of nodes and arcs.  (Let's call the union of
nodes and arcs entities.)  You also have attributes some of which
apply to nodes some to arcs and some to both.  The designer of one
attibute may specify it only applies to arcs, say a length attribute,
while another attribute may apply to nodes or arcs, say color.

    All of this is very expressible with generic style mix-ins.  And
notice that none of these restrictions dealt with the specific types
that are in each class.  This speicification comes at instantiation
time, when you assign attributes to entities.  And yes, you can
determine on a case-by-case basis whether an attribute is inherited or
not.  (Attributes can be defined so that they are always inherited, or
they can be defined so that the user determines whether or not they
are inherited for that entity type.)

    Incidently, for anyone who reads this far, I regard this more as
an exploration of the Ada 9X class model than a debate.  I keep coming
up with more and more semantic points to add to my list of things to
keep the same during the standardization process.  Between the current
stage of the work and a final standard lots of things will get lost so
that the final standard is consistant and implementable.  To make sure
that no useful features get lost, you need to know what they are.  As
an example, I realized up above that there will be cases where it is
necessary to nest a generic instantiation in a package which exports a
tagged type, and then rename some of the operations to make them class
wide operations that are derived by children of the tagged type.  Neat
feature, but we need to make sure it doesn't get lost:

       package Foos is
         type Foo is new T with private;
         function Baz return Foo'CLASS;
         ...
       private

       package body Foos is
         package Bar is new Foobar(Foo'CLASS);
         function Baz return Foo'CLASS renames Bar.Baz;
       end Foos;



--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...