Frank Heckenbach wrote:
Waldek Hebisch wrote:
ATM I think that we should have a single-rooted tree of exception classess which should be known to the compiler.
Indeed.
For compatibility with Delphi exception classess should be TObject descendants.
Or the other way around, i.e. let TObject be a descendant of the exception root (I'll call it TException in the following). This would be more Delphi compatible (every TObject could be an exception), and I'd prefer it for other reasons (TException didn't have to carry ballast from TObject).
Well, we have two things: - classes which may be exceptions - standard exception classes
In Delphi the first is just all Delphi classes = all descendants of TObject. The second is smaller.
For compatibility with Delphi our standard exception classes should be descendants of TObject.
Allowing exception classes outside of Delphi tree limits compatibility.
OTOH, I think TException should be a descendant of Root (no compatibility issues as OOE doesn't deal with exceptions; and Root doesn't carry much ballast).
So we'd have:
Root -> TException -> TObject
(About the drawbacks of letting TObject have a parent, see below.)
Maybe, but: - standard exceptions must live below TObject anyway - the balast of TObject is a bunch of VMT slots, it will matter only if you have thousends of different exceptions
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.
Not a big deal IMHO. ;-)
We would like to have a single "unified" dialect, but the options will allow quite a lot of variation. My reasoning was:
we want support the four object models (dialects)
we need support for migrating legacy code
we need support for "blended code" (code that works both with GPC and other compiler)
is handled by dialect options.
But dialect options in general are very strong options and have a lot of "side-effects". That's why I propose object-model-only options, which are part of the dialect options, but without all the other, unrelated, dialect stuff.
For 2) we need precise control, hence the detailed options.
Agreed.
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.
True, I hadn't considered this.
As you proposed, -fobjects-are-references and -fobjects-require-override would only apply to "object". Couldn't we also restrict -fdelphi-method-shadowing and -fbase-object= (or whatever it will become) to "class" only? Then
We could. But it means that BP (and possibly Mac) model will be less capable then others. Namely -fdelphi-method-shadowing makes sense as a step during back-porting from Delphi model to BP model (BP model is closer to C++, so such port while unlikely, is imaginable)
each object model option would only imply the former two options (for models that use "object") or the latter two (for "class"), so --bp-objects and --delphi-objects could happily coexist.
Well, one possibility is to make models disjoint. However, then we will need more options, since -fmethods-always-virtual currently affects also BP objects
Another possibility is: do all what dialect is doing to objects (it is probably what you originally had in mind). Then -fbp-objects would be a subset of -fdelphi-objects (or we could just make a single -fborland-objects). Then we will have:
-fborland-objects -fmac-objects -fooe-objects -fgnu-objects
The -fgnu-objects should reset things to default values
Waldek Hebisch wrote:
Prof A Olowofoyeku (The African Chief) wrote:
With regard to Root and TObject (OOE and Delphi), I have suggested elsewhere that one could probably be a silent ancestor of the other. In fact, they could be one and the same thing (with names changing, and/or members hidden or revealed depending on Delphi or OOE mode). I am not sure whether this makes any sense ...
I don't think hiding declarations based on directives is a good idea. The problems with the built-in `Result' should be a lesson to us (not quite the same, but a similar topic).
Consider the following program:
[...]
while pointer(c) <> nil do begin writeln(c.classname); c := c.classparent;However, if we add extra parent to TObject the first printouts would change. Note that while prp2 would crash on non-Delphi class, both prp1 and prp2 will work fine if we implement Delphi tree correctly.
Doesn't it depend on the definition of ClassParent (I suppose it's a Delphi builtin)? If we make it stop (return nil) at the Delphi root class, it would still work if there are other superclasses (kind of hidden from Delphi code then). I admit, it may not be the nicest feature, but perhaps better than the alternatives.
Cute idea. It has a drawback: ClassParent is generally usefull, also outside Delphi tree, so we would need a more general version. OTOH I would like to have multiple inheritance, so we probably want something different, which gives us all parents.
Prof A Olowofoyeku (The African Chief) wrote:
However, if we add extra parent to TObject the first printouts would change. Note that while prp2 would crash on non-Delphi class, both prp1 and prp2 will work fine if we implement Delphi tree correctly.
In which case, TObject and Root would need to be independent of each other.
This would make it difficult to write common code (including exception handling).
I am affraid that we will need multiple roots anyway.