Waldek Hebisch wrote:
Frank Heckenbach wrote:
[snip]
Generally I'm also wary of letting code generation depend on compiler options (though currently we do with `--methods-always-virtual'). So perhaps we should make the four models in default mode available with four different syntaxes (either two other names besides object and class, or keyword combinations, such as `virtual object' (= Mac) ??? etc., just fantasizing, or using attributes, or whatever). Then a default mode program could use them all without compiler directives. The dialect options would then only switch syntax, so e.g., in Mac mode, `object' means `virtual object', and other object models are forbidden.
I an not sure how Mac Pascal folks like `virtual object' but for me it looks fine.
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.
For example, the predefined object types could be:
TBPObject - establishes Turbo Pascal object model characteristics TDelphiClass - establishes Delphi class object model characteristics TMacObject - establishes MacPascal object model characteristics TOOEClass - establishes OOE class object model characteristics
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.
Note: I'm using TDelphiClass and TOOEClass as clarifying example names. 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.
What I'm trying to cover with the model characteristics term is things like methods-always-virtual (for the OOE and MacPascal object models), instantance variables are always references and implicit dereferencing (for the Delphi, OOE, and MacPascal object models), instantiation/destruction using new/dispose or constructors/destructors, and all the other model specific features and quirks.
Since all four models are, in esense, single inheritance models, the compiler should always be able to determine an object entity's model characteristics by following the object ancestor type chain back to the anchoring root type and thus determine whether particular syntax construct is legal or illegal for the object entity. (I'm using entity as a generalizing term to cover things like object type(s) in type contexts and object instantances in instantances contexts.) (Also, I didn't forget about OOE's "mix-in" property class. But I don't think you need anything special to handle that since OOE property class aren't really a stand-alone object - they always have to hang off of OOE's single inheritance backbone.)
To handle the ambiguities of base class/object type declarations, i.e.:
type TExampleClass = class {...} end; TExampleObject = object {...} end;
the language dialect option would set the default predefined root which the base class or base object inherits from for the dialect specified by the option. For example, option --borland-pascal sets TBPObject as the default root for base object type declarations and there is no class support.
For the --gnu-pascal option where both object and class are supported, there isn't anything which preordains the defaults to use for object and class but the defaults chosen should at least try to pair up the object and class models having the most similarities. [TBPObject, TDelphiClass] or [TMacObject, TOOEClass] seem to me to be fairly good similarites pairings; however, if there is a superdooper model gnu-pascal extension, TGPCClass probably should the default for class part of the pair and TBPObject for the object part of the pair. To declare a base class or object type of a model different than the --gnu-pascal, just use explicit class/object inheritance to inherit from the predefined class/object with the desired model charateristics. For example:
type TExampleObject = object (TMacObject) {...} end;
would declare a base object type having MacPascal object model charateristics.
For all three the MacPascal dialect compilers, there is an ObjIntf.p unit file which declares TObject as a base object which by convention is generally used as psuedo-root object type for user defined object types. So, for MacPascal object Pascal porters that used the TObject convention in their object type declarations, a small change to the TObject declaration in the ObjIntf.p unit would be all that it takes to port MacPascal objects to GPC.
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.
Gale Paeper gpaeper@empirenet.com