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.