Frank Heckenbach wrote:
Waldek Hebisch wrote:
In Delphi each class is a descendant of TObject. TObject has a predefined constructor called Create. As I wrote ATM the most visible difference between OOE/Delphi and our current implementation of classes is that we do not implement Root/TObject.
I belive that we can use a single type as both Root and TObject. Namely, TObject has more methods, but if we allow silent shadowing then the extra methods will be invisible to OOE programs.
But OOE doesn't allow silent shadowing (i.e., without `override'), does it? Do you propose to make a special exception for those particular methods?
Yes. More preciesly, I propose a special exception for Root/TObject class.
What would a common base type gain us? Existing code will always use the features of the base type of the model used, and not more. At least OOE doesn't allow multiple inheritance (what about Delphi?), apart from "property classes" which don't have a base type, so mixing of classes derived from different base types via multiple inheritance also doesn't seem a real issue to me.
There are two issues here. First, Delphi objects and OOE object can not be distinguished using syntax. Some differences have to be controlled by compiler switches (`-fmethods-always-virtual'), but I would like to hide as many differences as possible. I just noticed that Delphi `Create' is static, but in OOE all methods (so also constructors) are virtual. If the difference is observable then we would have to separate TObject from Root.
The second issue is single root vs. multiple roots. I have no strong opinion in favour of either (but since we already support multiple roots I see no reason not to do so in the future). In Delphi an OOE the _only_ way to create a class instance is to call a constructor. So, it is reasonable to insist that non-abstract classes have a constructor. Common base gives such warranty.
Another issue comes due to exceptions. In Delphi exceptions are classes. Once the exception is handled the exception object should be destroyed. So, it is natural to require that all exceptions have a "well known" destructor.
Peter N Lewis wrote:
Ok. Mac objects don't have any concept of Root or TObject base object (various class library frameworks have implemented their own base object, but that is a code level issue).
Same for BP OOP.
I guess as long as there is no significant overhead it would not matter if there was some invisible Root/TObject/base object, although personally I'd prefer to avoid it,
The overhead is mostly space: virtual methods tables need some extra slots (tens of bytes per class). Also, full TObject functionality would require much of symbolic information at runtime -- but it is some time before we start generating it.
I am more concerned about semantics, I am affraid that the presence/ absence of Root/TObject can be detected.
Me too (for BP OOP). I see no problem to add an implicit ancestor if no explicit one is given in Delphi and OOE, and not do so in the other two models.
I certainly do not want to mess with BP objects. I am not sure about Mac objects. For Delphi and OOE we have no choice. My current plan for implementing Root/TObject is to have extra module, with code included in RTS and .gpi file loaded at compiler startup. To compile this "builtin" module we need ability to have classes with no ancestor. There are other valid reasons not to add common base. But then we will have to add some restictions on use of classes not derived from "common base".