Waldek Hebisch wrote:
I would like to slightly update Mac objects and Delphi classes support. In particular I ma thinking about options names.
Good idea. I agree for the most part, except as noted below.
There is also question if constructors are mandatory for objects with virtual methods. ATM I think that we may tie this to object model: in value model (BP) make them mandatory, in reference mode make them optional. Namely, Mac objects have no constructors while OOE and Delphi will get them without any explicit declaration.
(Yes, from the implicit base object.)
I think I also wouldn't mind coupling it to the BP dialect option even. BP's implementation requires this, so for strict compatibility, we should offer to check this (it's only a warning ATM, anyway), otherwise I don't really see it required with GPC's implementation for any model. (In fact, I'd rather think about warning if in a model that has constructors at all, an object has no constructors -- regardless of whatever methods it has. This would be a more consistent demand, whereas the existing check is just to satisfy a detail of the BP implementation. Anyway, such a more general warning is not a high priority to me. I don't mean to implement it now. I just mention it to avoid overestimating the value of the existing warning.)
I propose to have the following options:
-fobjects-are-references -- choose reference model even if the declaration uses "object" keyword, on for Mac Pascal, off otherwise
(Yes, while `class' will always mean references.)
-fbase-object= -- to add default parent to object without an explicit parent
the last option will require some effort to implement.
It would also be a bit strange to have command-line options and/or compiler directives refer to syntactical entities (we don't do this in other options, apart from {$debug-tree} which is an internal debuging feature), and it might raise semantic questions if classes are renamed in import/export, perhaps even of questions scope (not easily, as object/class definitions have to be global -- I know this in BP and OOE, I suppose it's also so in Mac and Delphi --, but we might have to consider local imports, I didn't think this through yet).
An alternative would be to mark the root classes on declaration (in some way we'd yet have to thing about, whether a special directive, an attribute or whatever), and just have the options activate a previously declared (and usually imported, from the RTS) root class (more precisely, one of two possible root classes, for OOE and Delphi). Of course, it would be errors to declare more than these two potential root classes, or to activate one that wasn't declared, etc., but this shouldn't normally affect a user who uses the default RTS.
This is provided the root classes can be implemented in Pascal properly, without compiler magic. For OOE's Root, I see no problem (apart from the usual compiler magic for constructors and destructors). For Delphi, I don't know. But if it turns out that we do need magic, or that the compiler has to know the specific TObject class for some purpose, this would IMHO even more suggest making them special on declaration, rather then referring to them by name in an option.
Additionally, we may have -fmac-objects directive, which would be equivalent to sum of -fobjects-require-override, -fmethods-always-virtual and -fobjects-are-references.
plus -fno-delphi-method-shadowing -fno-base-object (i.e., so it sets the complete object model, not only turns on certain features. If one wants a mix, one can always give the deviating options afterwards).
I think we should have such an option for all four models, equivalent to the respective combination of positive and negative options. Also, the respective language dialect options should then imply the --foo-objects options (instead of the feature options directly, as e.g. currently --mac-pascal -> --methods-always-virtual).
Frank