From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Date: 18 Sep 92 22:08:10 GMT From: eachus@mitre-bedford.arpa (Robert I. Eachus) Subject: Re: MI - clutching at straws Message-ID: List-Id: 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...