Frank Heckenbach wrote:

Peter N Lewis wrote:

...

...

I have added a new option `--objects-are-references' (off by default, on for Mac Pascal) which choses reference model for objects. To get Mac semantics one has to use `--objects-are-references' and `--methods-always-virtual'.

Looks good. Can we add control over the warning:

warning: object type has virtual method, but no constructor

off by default in Mac Pascal, possibly off for objects-are-references?

What is the reasoning for the warning, why are objects supposed to have a constructor?

BP requires it. In fact, a constructor doesn't only have to exist, but must be called at runtime before virtual method calls will work. GPC doesn't require this, even in the BP model, so the warning is more for compatibility.

...

Are constructors ever called implicitly? As far as I could see, the only time a constructor was called was if it was passed to New when the object is created...? Should this be a BP compatibility warning only?

I think it should be coupled to the object model.

In OOE, the problem does not exist:

: 6.1.3.5 Constructors. : : There is a predefined constructor called Create in the Root class. Since : every abstract class and every concrete class is a descendant of Root, every : such class has at least one constructor.

Maybe the same is true for Delphi. If not, can a class not have a constructor there?

In Delphi each class is a descendant of TObject. TObject has a predefined constructor called Create. As I wrote ATM the most visible difference between OOE/Delphi and our current implementation of classes is that we do not implement Root/TObject.

I belive that we can use a single type as both Root and TObject. Namely, TObject has more methods, but if we allow silent shadowing then the extra methods will be invisible to OOE programs.

Waldek Hebisch wrote:

In Delphi each class is a descendant of TObject. TObject has a predefined constructor called Create. As I wrote ATM the most visible difference between OOE/Delphi and our current implementation of classes is that we do not implement Root/TObject.

I belive that we can use a single type as both Root and TObject. Namely, TObject has more methods, but if we allow silent shadowing then the extra methods will be invisible to OOE programs.

But OOE doesn't allow silent shadowing (i.e., without `override'), does it? Do you propose to make a special exception for those particular methods?

What would a common base type gain us? Existing code will always use the features of the base type of the model used, and not more. At least OOE doesn't allow multiple inheritance (what about Delphi?), apart from "property classes" which don't have a base type, so mixing of classes derived from different base types via multiple inheritance also doesn't seem a real issue to me.

Peter N Lewis wrote:

Ok. Mac objects don't have any concept of Root or TObject base object (various class library frameworks have implemented their own base object, but that is a code level issue).

Same for BP OOP.

I guess as long as there is no significant overhead it would not matter if there was some invisible Root/TObject/base object, although personally I'd prefer to avoid it,

Me too (for BP OOP). I see no problem to add an implicit ancestor if no explicit one is given in Delphi and OOE, and not do so in the other two models.

Frank

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.

but I would like to hide as many differences as possible.

I agree, but let's say, as reasonable possible (i.e., not at any cost). Root/TObject might be a questionable case ...

I just noticed that Delphi `Create' is static, but in OOE all methods (so also constructors) are virtual. If the difference is observable then we would have to separate TObject from Root.

The second issue is single root vs. multiple roots. I have no strong opinion in favour of either (but since we already support multiple roots I see no reason not to do so in the future). In Delphi an OOE the _only_ way to create a class instance is to call a constructor. So, it is reasonable to insist that non-abstract classes have a constructor. Common base gives such warranty.

Yes -- though I don't see this as a strict requirement. If (for some reason) we make it possible to create a non-abstract class without a constructor, the programmer will notice this no later than when he tries to instantiate it ...

Another issue comes due to exceptions. In Delphi exceptions are classes. Once the exception is handled the exception object should be destroyed. So, it is natural to require that all exceptions have a "well known" destructor.

Agreed. (In fact, I know of few, if any, cases where multiple destructors are really useful at all ...)

...

Peter N Lewis wrote:

...

Ok. Mac objects don't have any concept of Root or TObject base object (various class library frameworks have implemented their own base object, but that is a code level issue).

Same for BP OOP.

...

I guess as long as there is no significant overhead it would not matter if there was some invisible Root/TObject/base object, although personally I'd prefer to avoid it,

The overhead is mostly space: virtual methods tables need some extra slots (tens of bytes per class). Also, full TObject functionality would require much of symbolic information at runtime -- but it is some time before we start generating it.

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.

...

Me too (for BP OOP). I see no problem to add an implicit ancestor if no explicit one is given in Delphi and OOE, and not do so in the other two models.

I certainly do not want to mess with BP objects. I am not sure about Mac objects. For Delphi and OOE we have no choice. My current plan for implementing Root/TObject is to have extra module, with code included in RTS and .gpi file loaded at compiler startup. To compile this "builtin" module we need ability to have classes with no ancestor. There are other valid reasons not to add common base. But then we will have to add some restictions on use of classes not derived from "common base".

We're getting into some kind of bootstrapping problems here.

Sorry for getting a bit off-topic, but basically, I'd also like to do some other things via automatically loaded (RTS) .gpi files in the long run. Many of the predefined routines, which are not completely inlined, could be handled this way. The compiler would handle any nonstandard syntax and semantics and then call the RTS routines normally. E.g., given `WriteLn (foo : 42)', the compiler would check the type of foo, and then call, say:

_p_Write_Integer (Output, foo, 42); _p_WriteLn (Output);

where _p_Write_Integer and _p_WriteLn would then be standard Pascal routines declared in the RTS. Well, actually, it's almost so already, except that the binding is now done via linker names rather than GPI declarations, so apart from removing one possible source of interface mismatch and therefore ease maintenance, the change wouldn't gain much in practical terms immediately. That's why it's not high priority to me. (Until we had qualified identifiers, it wasn't really possible to do so, now I think it's possible at least ...)

There are bootstrapping problems there, too, in particular if the RTS is split into several modules, as it is now (and anything else would seem unreasonable). E.g., if one RTS module did a `WriteLn', but the module containing `_p_WriteLn' wasn't imported yet, it would fail with a missing declaration. (Of course, we're a bit outside of standard Pascal semantics here ... ;-) But these kinds of problems can probably be solved using cyclic module dependencies (sigh), and reordering the RTS to reduce the amount of affected code. (I expect there will be a core of interdependent low-level stuff, including basic I/O, well at least output, as well as error handling, and a few string operations, and then a larger part of code that builds upon it in a more acyclic way.)

But another, more elementary thing that will come up then is that while compiling the RTS, the compiler must be told not to automatically import the RTS (even if it exists from a previous build, of course). So I think we need a special option here, and perhaps this options could also applied to the special needs WRT the base object type. Something like: This "bootstrap" option disables the automatic base class for Delphi/OOE classes. And perhaps also marks such a class to become the default base class for regular compilations later. (This way, the names TObject and Root would not need to be "magical".) Depending on the question discussed above, we will need one or two such "slots" for the two relevant models. Since this option should be used only in the RTS, we could make sure there that no strange things are done with classes that have no base class. (Of course, those who'd write their own RTS would need to check this for themselves.)

These are just some thoughts. I probably haven't considered all issues yet, and I'm not completely convinced that coupling these two things (no auto import, no auto base class) is good, but at first sight, there seems to be some correlation ...

Frank

On 8 Aug 2005 at 5:24, Frank Heckenbach wrote:

[...]

As I wrote sometime, I think I'd prefer a "object model" switch.

This makes much sense.

[...]

...

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.

We could do it this way, in the RTS ...

Type Root = Class OOE stuff ... end;

TObject = Class (Root) Delphi stuff ... end;

So if Borland change TObject, this needn't cause any incompatibility with Root. The question though is whether the fact that TObject then becomes a subclass of another object is problematic for Delphi compatibility ...

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

On 8 Aug 2005 at 21:05, Frank Heckenbach wrote:

Prof A Olowofoyeku (The African Chief) wrote:

...

[...]

...

...

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.

We could do it this way, in the RTS ...

Type Root = Class OOE stuff ... end;

TObject = Class (Root) Delphi stuff ... end;

So if Borland change TObject, this needn't cause any incompatibility with Root. The question though is whether the fact that TObject then becomes a subclass of another object is problematic for Delphi compatibility ...

This is one question which perhaps you can judge better than us.

Well, if Root is inaccesible to programmers in the Delphi object mode (and it should, IMHO), then I would imagine that there shouldn't be a problem.

Of course, we must ensure that either Root or TObject becomes the implicit parent, depending on the mode.

Indeed.

The other question is if Root is in fact a proper ancestor of TObject (not by definition, of course, but perhaps by their features). Have you, or someone else, checked this?

AFAIK, in Delphi, TObject has no ancestor, either by definition or feature. It is an abstract object that is simply "TObject = Class". But then it also becomes the implicit ancestor of anything defined as "Class". Perhaps there is something circular or recursive going on here?

If so, this might be a good idea, as OOE is unlikely to change soon (and thus Root to add features), neither Delphi to drop existing features from TObject.

Precisely my thinking. The secret, as I see it, is to completely hide Root in Delphi mode. If this can be done, then I don't think it matters that TObject is a subclass of Root.

PS: I don't think there is any need to hide TObject in OOE mode, as long as it is not the implicit ancestor object in that mode. Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/

On 9 Aug 2005 at 19:18, Frank Heckenbach wrote:

Prof A Olowofoyeku (The African Chief) wrote:

...

...

The other question is if Root is in fact a proper ancestor of TObject (not by definition, of course, but perhaps by their features). Have you, or someone else, checked this?

AFAIK, in Delphi, TObject has no ancestor, either by definition or feature. It is an abstract object that is simply "TObject = Class". But then it also becomes the implicit ancestor of anything defined as "Class". Perhaps there is something circular or recursive going on here?

This would be what I meant by definition. By their features, I mean that someone would have to compare the features of TObject in Delphi and Root in OOE and verify whether the latter are a proper (and compatible) subset of the latter. Perhaps Waldek or someone else has done that already, but I don't know ATM. If that's not the case, I think this idea will fail.

I can't see any incompatibility. The OOE docs says this:

"6.6.2 Root. The predefined identifier Root represents an abstract class that is the parent of all user-defined concrete and abstract classes. The Root class has as its interface the methods that are specified in the following subsections. The Root class is defined as follows:

TYPE Root = ABSTRACT CLASS CONSTRUCTOR Create; DESTRUCTOR Destroy; FUNCTION Clone : Root; FUNCTION Equal (R : Root) : Boolean; END; NOTE: An implementation can add other things to the class Root."

This looks pretty compatible with TObject to me. TObject has a Constructor called "Create" and a destructor called "Destroy". It doesn't have "Clone" or "Equal".

The OOE docs say this about the constructor and destructor:

"6.6.2.1 Create. Create is a constructor with no parameters. Its action is to create an object of the class in which it is used. When overridden, the programmer can specify additional actions to be taken after creation.

6.6.2.2 Destroy. Destroy is a destructor with no parameters. Its action is to destroy the object. When overridden, the programmer can specify additional actions to be taken before the object is destroyed."

Nothing in these is incompatible with TObject (indeed, they seem to have precisely the same function).

As for "Clone", I have no idea what the OOE docs mean when they say this:

"6.6.2.3 Clone. Clone is a functional method without parameters. It returns the result of the predefined function Copy. NOTE: The recommended method of redefining Clone is to specify inherited Clone as the first operation in the overriding method. This way, the clone is built in a top-down fashion."

This is the blurb about "Equal":

"6.6.2.4 Equal. Equal is a functional method that compares two reference values. It has one parameter: a reference to an object. If not overridden, its action is to return True if the parameter is a reference to the same object as Self; otherwise, it returns False."

Therefore, since Root only has these four methods, and no fields, it seems that it can quite properly be an ancestor of TObject.

...

PS: I don't think there is any need to hide TObject in OOE mode, as long as it is not the implicit ancestor object in that mode.

I think the "need" is just the same as for hiding Root in Delphi mode (as long as it's not the implicit ancestor). Both may not be strictly required, but would be in accordance to our policy of only allowing the dialect's features in a dialect mode.

TObject has much more than Root. If I were to use the OOE object model, I might still want to take advantage of the added functionality of TObject (and this is not in anyway incompatible with OOE). OTOH, the concept of an ancestor for TObject in the Delphi model can lead to potential incompatibilities, hence the need to hide Root in that model.

Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/