Multiple inheritance (Was: OOP)_(re)

Fri, 30 May 1997 01:16:39 -0400 (EDT)

On Thu, 29 May 1997, The African Chief wrote:

> No. C++ is clumsy and bloated. However, the problem is that MI is part 
> of the language definition. If it were to be implemented in GPC, it wouldn't
> be part of any definition. It would just be a local extension that could be
> ignored by anybody who so wishes. I don't see that having such an
> extension is so bad. Some day, someone will want to use it, and it 
> doesn't help to tell them that they don't need it.

MI is a source of infinite complexity. And beside, local extensions aren't
a very good idea...

> A purely personal thing, perhaps. If I did it my own way, without any
> preconceived notions, I would have an ancestor object which would
> contain everything that I think every object should have. What I think
> every object should have changes from time to time, and therefore, for
> me, it is better to start with more, than with less ;-)

I'd be very curious to see your CHIEFAPP class library. You seem to be not
very experienced regarding OO design... You indeed are right that the
ancestor object should contain everything *every* objects should have, but
think about this: what will *EVERY* objects have?

> > I really don't see what a TWindow object and a
> >TString object has in common that should be in TObject! 
> 
> They could all have a Name, a SelfID, a Parent, and a Child.

The name isn't very useful, the SelfID isn't much either, the parent could
be nice, but would be better implemented as a function interrogating the
VMT (so you can use the "Parent" identifier in your class for a method
name or property name). Child can be deduced by walking the VMT parenting
tree but could be implemented like the Parent...

> >BP didn't set that
> >trend BTW. The Smalltalk anscestor object doesn't do *ANYTHING*. 
> 
> The first thing I would do to it is to change that omission ;)
> 
> And what is the point of have the ancestor then - just for type
> compatibility ?

Exactly. Did you actually ever instantiate a TObject??? If not, then why
have anything in it, you won't use it anyway! Descendent have their own
properties and methods.

> >BPs constructor fills the object with zeros for instance. :-) 
> 
> Not very useful at all. They might as well not have any constructor
> or destructor.

Well, this actually *is* a very personal choice, but I like to know for
sure that when the constructor has been called the object is "empty". But
there should be both a constructor and a destructor in any cases, because
the destructor is virtual (and thus you can dispose of *any* object
descended from TObject with a Dispose(P, Done);) and having a default
constructor is a good thing.

> >The use is in
> >having the POBject pointer type handy, that can handle *any* objects. You
> >have a single TCollection that can handle both TWindow objects and TString
> >objects, even a *MIX* of those! *This* is what TObject is there for, not
> >have a heap of methods.
> 
> Ok. Let's just say we have a difference of opinion there! My experience
> in writing my CHIEFAPP class library has led me to a different conclusion
> about what an ancestor object should be like. In the end, I suppose that 
> these things are a matter of personal preference!

Hmm... That's part of OO design, it takes *longer*, but you profit from
code reuse and good design much more than with procedural programming.
Could you send me the root unit (the one containing the basic classes) of
your CHIEFAPP class library?

Pierre Phaneuf

"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." - Edsger W. Dijkstra.



Pierre Phaneuf (pp@dilu.ml.org)