Multiple inheritance (Was: OOP)_(re)

Thu, 29 May 1997 11:18:05 +0100 (BST)

On Wed, 28 May 1997 20:46:54 -0400 (EDT) Pierre Phaneuf  wrote:
>On Wed, 28 May 1997, The African Chief wrote:
>
>> If it can be done, then it should be done. However, I would advise
>> against using it in the RTS or in any UNIT supplied as part of the GPC
>> distribution. Let us make it's use completely optional (i.e., people can
>> use it in their own programs if they want, but GPC is itself free from it.
>
>Well, removing GOTO is another thing that could be done. Maybe we
>shouldn't do that, but *please*, let's not add multiple inheritance to a
>language whose goal is to be the Right Thing and to be simple. Do you know
>how many pages there is in the C++ standard? Its something in excess of a
>*thousand*. Do we want *that*? 

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.

Also note that Java has been widely

>> I think this is better than using MI. BP seems to have set the trend to
>> have an almost useless ultimate ancestor for an object heirarchy. I
>> personally do not agree with that philosophy. 
>
>Why do you disagree? 

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 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.

>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 ?

>BPs constructor fills the object with zeros for instance. :-) 

Not very useful at all. They might as well not have any constructor
or destructor.

>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!

Best regards, The Chief 
Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant)
Author of:  Chief's Installer Pro v3.50 for Win16 and Win32.
Homepage:  http://ourworld.compuserve.com/homepages/African_Chief/
E-mail: laa12@cc.keele.ac.uk


The African Chief (laa12@cc.keele.ac.uk)