At 5:24 +0200 8/8/05, Frank Heckenbach wrote:
Waldek Hebisch wrote:
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'),
As I wrote sometime, I think I'd prefer a "object model" switch. Individual feature switches can also be added (or remain existent, such as `--methods-always-virtual'), but it's unreasonable to expect a programmer to know all different features, instead of setting a particular object model.
I agree. I think ideally there should be a set of options like:
-fmethods-always-virtual -fobjects-require-constructors -fobjects-require-override -fbase-object=Root
(it'd be nice if you could specify the base object by name, since then you could implement your own base object outside the RTS for your own framework, but alternatively, the options could be -fbase-object-Root, -fbase-object-TObject, -fbase-object-none for example)
and then
fobject-model-bp (or -delph or -mac or -ooe (or =BP, =Delphi as you prefer)) simply sets all the related parameters.
I am more concerned about semantics, I am affraid that the presence/ absence of Root/TObject can be detected.
Quite possible. Also we should consider that Borland may change TObject in future versions. If we decide that we can, and want to, identify it with Root now, and later they change it so it's not compatible anymore, we'll have a problem.
And another thing to be very careful of for the above orthogonallity to come close to working is that the RTS will have to be very delicate in both its definitions of the base objects and any use of objects.
Anyway, just some thoughts. Peter.