Hi all,

I'm trying to reduce the gap between traditional Mac Pascal object models and GPC's current object model.

Frank's already added an option in to turn virtual on for all methods automatically, so that's reduced one major incompatibility. The other one is that in Mac Pascals, object is implicitly a pointer and implicitly dereferenced. That is:

type myobject = object v: Integer; procedure method; end; var obj: myobject; begin New( obj ); obj.v := 5; obj.method; end.

In GPC, object is more like a record, and typically you create a pointer to it an New that, ie:

type myobject = object v: Integer; procedure method; end; myobjectptr = ^myobject; var obj: myobjectptr; begin New( obj ); obj^.v := 5; obj^.method; end.

What I'd like added to GPC is a compiler switch like {$implicit-object-dereference} which allows

obj.field to be a synonym for obj^.field in the case where obj is a pointer to an object.

This would remove most of the incompatibilities, particularly it would remove all the ones in normal use of code (at least as far as I can see).

The only remaining issue would be when defining an object you need define an explicit pointer. Ideally this could be handled by another option, or perhaps the same option perhaps renamed {$implicit-object-pointers}, which would convert:

type myobject = object...

in to defining myobject as a pointer to that object, and allow the cases like

type mysubobject = object(myobject)...

However, that latter half is not absolutely required as there are relatively few object definitions and they can be conditionalized otherwise. The primary issue is the first one since otherwise every single object access would have to be conditionalized which would be unpleasant to say the least.

I can't see any real drawback with an option to allow implicit dereferencing of an object pointer, it looks to be unambiguous since otherwise objp.field will just give an error complaining about the lack of ^. This also has no compatibility issues with GPC objects.

Making all objects implicitly pointers is a somewhat larger change, and this would be incompatible with GPC objects, so it is not so clearly a good idea. I think it'd still be helpful to enable source code compatibility, but it can at least be worked around with a finite amount of conditionalizing or macro hacks.

So, and thoughts on this, one way or the other?

Thanks, Peter. PS: I've currently got 35 files with around 15,000 lines compiling in GPC, most of it compiling also in CW. So objects aside, it's currently relatively straight forward to get CW/GPC compatible source code which is wonderful!

Prof A Olowofoyeku (The African Chief) wrote:

On 15 Jul 2003 at 10:07, Peter N Lewis wrote:

...

Hi all,

I'm trying to reduce the gap between traditional Mac Pascal object models and GPC's current object model.

Frank's already added an option in to turn virtual on for all methods automatically, so that's reduced one major incompatibility. The other one is that in Mac Pascals, object is implicitly a pointer and implicitly dereferenced. That is:

type myobject = object v: Integer; procedure method; end; var obj: myobject; begin New( obj ); obj.v := 5; obj.method; end.

[...]

What you are describing is almost equal to the "new" style Delphi Classes (actually, this is already over 7 years old, so it is not so new - but I use "new" here to distinguish it from the original BP object model). That type of Delphi compatibility, is, I believe, on the to-do list - but perhaps not a high priority.

At least not for me ...

But actually, this part (automatic pointer dereference) seems comparably easy to implement (at least I hope so), and if, as Peter told me, it would help Mac Pascal source compatibility quite a bit, it might be worthwhile to do this in isolation.

The main difference between what you propose and Delphi is that, under Delphi, you must call the object's constructor before you can do anything with it. The constructor call allocates memory for the object and returns a pointer to it (e.g., "obj := myobject.myconstructor"), and deferencing is automatic.

AFAIK, there are also differences to Mac Pascal in con-/destructing, but these are not so pervasive in the source, so Peter would rather work-around those.

In fact, I'm more afraid of the automatic destructing, but also the constructing probably requires some effort ...

But you must use "Class" when defining the object, and not "Object" (e.g., type myobject = class ....).

If your suggestion is accepted, then we might one day have 3 kinds of GPC objects - the old BP objects, the Delphi classes, and the Mac Pascal objects. I am not sure where this will lead us.

Probably the same as always (a mess of different dialects, with few real conflicts if we're lucky) ... :-/

Perhaps the Mac Pascal object type could be implemented as a superset or subset of the Delphi Class (or vice versa), since implementing one will have taken us almost to the point of being able to support the other.

Unfortunately, as you noted, Mac uses `object', so there is a conflict to BP objects. (The conflict might not show here, since there may not be any code that is valid in both models, with different meanings, since `ObjPtr.FieldOrMethod' in BP and `ObjPtr^.FieldOrMethod' can never be valid. There might be real conflicts with constructors, but as I said, I won't do them now, anyway.)

There should still be an option for automatic pointer dereferencing since it weakens the typing, so it shouldn't be on by default (unless in --mac-pascal).

I suspect that none of this is a great priority at the moment - but I might be wrong ....

Again, not to me. However, I might be able to do the automatic pointer dereference (or FTM adding `class' equivalent to `object', if it may help, i.e. reduce the Delphi differences to con-/destructing), if it turns out not too hard and doesn't have negative implications.

That's why I suggested to Peter to ask on the list, so anyone can think of whether there may be any hidden problems. (I'd prefer not to discover them in the middle of the implementation.)

And, of course, to send some test programs (for partly Mac, and perhaps partly Delphi compatibility int hsi regard).

Frank

As I see it, the differences between Mac objects and GPC objects are:

1. methods are always virtual
2. objects are created/destroyed with New/Dispose
3. objects are implicitly pointers
4. fields are implicitly dereferenced
5. there are no (user) contructors/destructors

Morning

If memory serves, Delphi object are 'references' and not pointers. This may be semantics. In Delphi object variables contain pointer to code and a separate pointer to the instance data segment. This maybe be why MyObject := tAnotherObject.Create form is used instead of typical New( MyObject, Create);