🚀 go-pugleaf

Sorry, a little late..

William D. Gooch wrote:
> In article <4ku8rq$pav@cubenx.cube.de> hhoff@cube.de (Holger Hoffstaette) 
writes:
> 
> >William D. Gooch wrote:
> >> 
> >> Gosh, hasn't this been discussed enough before?  MI has 
> >> great value when used appropriately.  Added complexity 
> >> and indirection in instance structures or redundant code 
> >> are essentially the only ways to compensate for its lack. 
> 
> >Yeah, it's also a great way of preventing you from fixing third-party
> >classes that are Broken By Design(tm).
> 
> What do you mean by "preventing?"  MI is an added 
> capability, and prevents nothing that I can think of.

Many of the C++ class libraries I've seen that use MI have serious
problems - they either fall over at the slightest tip (trigger one
extended part, see the rest of the heirarchy fall) or, even worse,
are just *wrong* when it comes to the modeled class hierarchy.
I can not 'untangle' the given mess by overriding or 'flattening' the
inheritance hierarchy. Inserting a delegate can get you around this,
but it usually leads to the bloat you mentioned if not done properly
(i.e. carefully); you might end up inserting more delegations than you
planned. SI systems are probably simpler (easier?) in this regard.

> >Some of us have *real* protocols & forwarding, and get by great without
> >unnecessary code bloat or weirdo design. MI - thanks, but: No Thanks!
> 
> Certainly you are free to not use MI, whether or not the 
> language supports it.  In my experience, properly used 
> MI helps in avoiding "code bloat," as I pointed out before.

'Properly' used - sure!

> "Forwarding" (delegation) is an example of the indirection 
> I was referring to, and what you mean by "*real* protocols"
> is not at all clear.  (Apparently this is something that can't

Forwarding is great and IMHO used way too little, maybe because many
people don't know something like it exists, or how easy, yet powerful
it is.

By real protocols I meant protocols (interfaces, capabilities) that can
be 'attached' to a class anytime, anywhere; they should be optionally
inheritable, mixable without conflict, addressable and speakable over a
wire (distributed objects). I use Objective-C and it comes pretty close
(which has a lot to do with the environment I'm in (NEXTSTEP), but then
again, that's no coincidence).

My Smalltalk is a bit rusty (we -are- wasting c.l.s space, right? :), but
I don't think you can ask an object if it conforms to a certain
protocol/category/whatyoucallit; methods only, if I remember correctly.
No way in C (now that would be fun) or C++. RTTI is little help, asking
for or knowing a 'type' (the word tells) doesn't give me a clue whether
the object I'm talking to actually knows what I'm talking about or not!
I think what I'm trying to say is that capabilities/interfaces are good
and too rigid hierarchies are bad. (cf. the follow-up by Matthias Blume).

> be accomplished in a language which supports multiple 
> inheritance?  Very interesting.)

I'm not sure if MI in principal prevents something like I described above;
it probably depends on the implementation and method dispatch semantics of
the particular language.

> You'll need to define "weirdo design" (is that a technical 
> term?) before I can respond to that part.

When Holy Wars get tough, the techies get weirdo.

Read: both MI and delegation/forwarding can be used easily to botch up
royally (what's new?). MI can get you in the mud quickly and you can't
get out anymore; excessive delegation can make you sink slowly, but
surely. Your choice. :)

I've had my head in large delegation-based systems (ObjC, Smalltalk)
that virtually collapsed because of a system-wide broadcast (delegation)
'storm' that just never seemed to end, yet was necessary (or *thought* to
be necessary) to keep the system in a consistent state. These I call
'weirdo' designs, since they usually show that the corresponding project
has gone insane: prime directive #1 is to try to catch up with a design
mistake made in the beginning, although you *know* that it cannot be caught
and fixed without major surgery.

> Truly folks, I had no intention of starting a flamefest here.
> I am at a complete loss to understand the vehemence with 
> which some people appear to dislike multiple inheritance.

I once had a look at Taligent's 'frameworks', which use(d?) mix-in
classes (probably the most often use for MI) excessively.
The whole thing was about as readable as a brick in the face. IT HURT.
Maybe I was just too dumb for it, but then again, it was probably too
hard for the other 98% of the programming world, too!
It certainly seemed to be too hard for the guy doing the presentation,
trying to explain what it was all about.

> My experience with it has been quite good (and I have also
> learned to do fine without it, since I am currently working 
> in Smalltalk).  If there is something substantive behind this 
> very emotional reaction, it has yet to become clear to me.
> If someone can explain this in terms other than "many
> people use MI badly," I would really appreciate it.

Today, a disproportionately large amount of code is still written by people
who have no or only insufficient CS education, nor intensive OO training;
they were electricians, salespeople, teachers or physicians in previous
lives, and usually grunt COBOL or VisualBasic (if they're really advanced).
Now that's fine, but letting these people play with MI (preferrably in C++
after a 'Learn The Magic of OO Really Fast In 5 Days Because The Boss Told Us'
is like giving them a bazooka to swat a fly. Granted: this is very emotional
and absolutely no reason for an *objective* view on MI, but it is nevertheless
a very real one. Before someone tells me that this is no reason to take away
the Sharp Knives from The Experts: I agree!

Interestingly enough, these more 'naive' users of C++ use MI to simply
add functionality, just like mix-ins. Of course, neither do they know that
they're using mix-ins, nor are the trunk class or its mix-ins properly thought
out, but that has never stopped anybody, right?

> I do think there's a serious lack of adequate instruction on 
> the proper use of MI.  Perhaps this can be rectified.

I too would certainly like to see some *good* examples where MI fits in,
properly modeling a certain domain problem. Code NOT written in C++ gets
bonus points!

By the way: should'n this go into comp.object (only)?


Regards,

Holger
(playing devils' advocate ;)
--
  ___ 
 /\__\  Holger Hoffstätte               net: hhoff@cube.de (MIME, NeXT, PGP)
 \/__/  Cube Informationssysteme GmbH   vox: (+49)0711-90669-0 (or -11)
[kju:b] Stuttgart, Germany              fax: (+49)0711-90669-16