Frank Heckenbach wrote:
Waldek Hebisch wrote:
-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).
I agree that such thing makes more sense as na option (affecting the whole file) then as a (possibly local) directive.
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.
ATM I think that we should have a single-rooted tree of exception classess which should be known to the compiler. For compatibility with Delphi exception classess should be TObject descendants.
Implementing such classes in Pascal seems much easier then hardcoding class declaration in the compiler. The -fbase-object= option looks like the easiest way to implement Root/TObject. Actually, before things stabilize I would like to Root/TObject to be user level code, outside of RTS proper. But I agree that such option may be too dangerous/confusing for users.
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).
Hmm, I was affraid that I already propose too many options. We would like to have a single "unified" dialect, but the options will allow quite a lot of variation. My reasoning was:
1) we want support the four object models (dialects) 2) we need support for migrating legacy code 3) we need support for "blended code" (code that works both with GPC and other compiler)
1) is handled by dialect options. For 2) we need precise control, hence the detailed options. For 3) our current dialect support is too weak, we frequently have equivalent functionality as other compilers, but using different syntax. So "blended code" have to use full GPC language + macros and conditionals. For bulk of the code it is (or will be) possible to have the same source, with the notable exception of Mac Pascal -- hence I proposed specific option.
BTW: BP and Delphi models coexist in a single compiler (namely Delphi itself). So while meaning of -mac-objects looks reasonable clear to me the other look more fuzzy.