On Wed, 28 May 1997 20:46:54 -0400 (EDT) Pierre Phaneuf pp@dilu.ml.org 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