Waldek Hebisch wrote:
Gale Paeper wrote:
Instead of special syntax and compiler options, I thinking some sort of predefined abstract root object type for each of the four object models which establishes and fixes the model characteristics of the object inheritance tree rooted on the respective predefined object model type might be the better way to handle supporting the different object models.
I do not think so.
Me neither. I agree with Waldek's arguments. In addition pelase note that the BP model doesn't have one single root object, and it's common (at least for some programmers, including myself) to have various unrelated inheritance trees in a program. So one would have to specify "BP model" everywhere (in particular, as I don't compile with a BP options as I use many non-BP features otherwise).
Gale Paeper wrote:
For thrill seekers who are looking for a kitchen sink, does everything object model, you could add TGPCClass which (somehow) merges all the characteristics of the four other models into one superdooper model.
Unfortunately this seems impossible as in some respects the models conflict directly. E.g., are all methods virtual, or not? They can't both be and not be at the same time (in a "superdooper model"). So I think we need the distinction.
Delphi does have TObject as a predefined root object that all classes inherits from and OOE has the predefined Root abstract object type which all user-defined concrete and abstract classes inherits from so those predefined identifiers would probably be best to use for implementation.
AFAIK, several BP class libraries also use `TObject' (as a regular object type with no special properties). This would be conflicting or at least very confusing (e.g., when imported).
For the four predefined TBPObject, TDelphiClass, TMacObject, TOOEClass type, I don't think it is adviseable to try any sort of mixing. For those needing or wanting GPC support for one of those object models, I think the GPC capailities they want most is just to get a working implementation of the present model type capabilites and features.
But this would further support the balkanization of class libraries. I don't want GPC to become "N compilers in one" that N groups of programmers use in N different and incompatible ways, and in the end will implement each technique N times. Mixing of dialects has been a strength of GPC, and I'd like it to remain so with OOP.
For most other points, I agree with Gale, but in the end I think the advantages of mixing (by inheritance) outweigh.
Frank