On Wed, 28 May 1997 12:08:20 +0200 (MET DST) Peter Gerwinski peter@agnes.dida.physik.uni-essen.de wrote:
According to Pierre Phaneuf:
I strongly advises *agains't* multiple inheritance. It is the OOP 'goto' equivalent. Everything MI can do, you can do without MI if you design well. C++ is the bloated monster we know today in part because of that pseudo-feature. Neither Modula-3 or Oberon has multiple inheritance and both have been used in programming operating systems and huges projects.
I don't vote for or against multiple inheritance,
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.
but
- are there existing Pascal standards (ANSI Object Pascal, Delphi) requiring it? (I *really* don't know.)
Delphi does not do MI.
- There are few places in my planned object hierarchy (I am *also* working on a completely new library;) where MI could be useful: There are several independent branches of recursive objects, say `VisibleObj' and `DataObj', which all have a `Child ( i: Integer )' method returning the `i'th child. It would be nice to implement some stuff, say a `ForEach' method, in a common ancestor. Without MI, this common ancestor must be a *very* "low" object, `BaseObj' itself, the parent of all objects. I am not sure if it is wise to make *every* object in the hierarchy potentially recursive.
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.
(* And: C++ has it, and we must demonstrate that GPC is not inferior. ;*)
Agreed :-)=
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
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*? Also note that Java has been widely recognized as "C++ as it should have been" (by Bjarne Stroustrup among others, the designer of C++), and Java *doesn't* have multiple inheritance.
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? I really don't see what a TWindow object and a TString object has in common that should be in TObject! BP didn't set that trend BTW. The Smalltalk anscestor object doesn't do *ANYTHING*. BP's constructor fills the object with zeros for instance. :-) 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.
For instance, I tried to make my class as much object-oriented as possible, free of any procedures. For example, Abstract has been made a method of TObject and a similar NoStream method has been added to prevent streaming of non-streamable objects (this is very quite not final, susceptible to removal).
A thing that would be better to have than multiple inheritance would be pure virtual methods. Would allow me to remove that Abstract method! ;-)
Pierre Phaneuf
"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." - Edsger W. Dijkstra.