With the recently announced move by Apple to convert the Mac platform over to Intel processors (at least initially still closed hardware, but with an Intel processor instead of a PowerPC) starting next year and completing the transition in 2007, the need for Pascal users to move from Metrowerks CodeWarrior Pascal to XCode/GPC (or FPC) is now much more immediate.
I presume since GCC can build a fat bundle application for both PPC and x86 that there will not be any problem with GPC doing that too.
So the primary problem that remains is the difference between Mac style objects and Borland style objects which we've discussed before. The primary requirement as I see it is the ability to write code where the use of the objects is source compatible (possibly using Macros if necessary), and the object definition has as few changes as possible, preferably also handled by macros.
As I see it, the minimal changes required are:
1. Allow objectptr.field as a synonym for objectptr^.field (currently this would be an error, so it is a relatively safe allowance)
2. Allow type newobject = object(objectptr) ... end; (currently this would be an error, so it is a relatively safe allowance)
3. Support the "override" keyword and add a compiler flag to require it.
4. Add a compiler flag to disable the "virtual" keyword and make all methods virtual by default.
5. Preferably add a compiler flag to say "objects are pointers" which simply adds an implicit pointer reference to the object type definition, ie:
type myobject = object(superobject) ... end;
implicitly becomes
type myobject = ^object(superobject) ... end;
Without this change, but with the other changes, the user could change the object definition from:
type myobject = object(superobject) ... end;
to
type myobject = ^myrealobject; myrealobject = object(superobject) ... end;
which is workable, but a bit ugly to have to do for every object definition.
If a small amount of funding would help make this happen, I can look at trying to drum some up (just give me a figure, perhaps off-list).
Any possibility of this happening. I'd rather not have to try to delve into the compiler to try to figure this out myself as they are clearly quite technical changes (although generally I suspect mostly not too challenging if you know what you're doing with the compiler source already).
Thanks, Peter.
On 9 Jun 2005 at 11:44, Peter N Lewis wrote:
With the recently announced move by Apple to convert the Mac platform over to Intel processors (at least initially still closed hardware, but with an Intel processor instead of a PowerPC) starting next year and completing the transition in 2007, the need for Pascal users to move from Metrowerks CodeWarrior Pascal to XCode/GPC (or FPC) is now much more immediate.
I presume since GCC can build a fat bundle application for both PPC and x86 that there will not be any problem with GPC doing that too.
So the primary problem that remains is the difference between Mac style objects and Borland style objects which we've discussed before. The primary requirement as I see it is the ability to write code where the use of the objects is source compatible (possibly using Macros if necessary), and the object definition has as few changes as possible, preferably also handled by macros.
As I see it, the minimal changes required are:
- Allow objectptr.field as a synonym for objectptr^.field
(currently this would be an error, so it is a relatively safe allowance)
- Allow type newobject = object(objectptr) ... end;
(currently this would be an error, so it is a relatively safe allowance)
Support the "override" keyword and add a compiler flag to require it.
Add a compiler flag to disable the "virtual" keyword and make all
methods virtual by default.
- Preferably add a compiler flag to say "objects are pointers" which
simply adds an implicit pointer reference to the object type definition, ie:
type myobject = object(superobject) ... end;
implicitly becomes
type myobject = ^object(superobject) ... end;
Without this change, but with the other changes, the user could change the object definition from:
type myobject = object(superobject) ... end;
to
type myobject = ^myrealobject; myrealobject = object(superobject) ... end;
[...]
Most of these changes are implicit in Delphi-style "Classes", which I believe, are on the GPC "to do" list. Once GPC gets the "Class" type, there will be no need to do any of these. So I guess what you are pushing for is a quick implementation of Classes. I am not sure myself that this would be a trivial undertaking. However, I'll leave Frank and Waldek to speak to that point.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
Most of these changes are implicit in Delphi-style "Classes", which I believe, are on the GPC "to do" list. Once GPC gets the "Class" type, there will be no need to do any of these. So I guess what you are pushing for is a quick implementation of Classes. I am not sure myself that this would be a trivial undertaking. However, I'll leave Frank and Waldek to speak to that point.
Certainly not trivial, and in addition, all of Mac, Delphi and OOE objects/classes are slightly different.
Well, my next bigger changes in GPC according to my plans were going to be the preprocessor and then short strings, but perhaps I should change my priorities now. I suppose the preprocessor is still urgent, as it makes GPC more or less difficult to use (depending on the platform) with gcc-3.3.x and higher. But as I understand it, you have work-arounds for short strings, so perhaps classes are more urgent then.
I can't speak for Waldek, of course. ATM, he's busy with the gcc-4.x port and backend fixes. Do you plan to work in any of the above areas soon (say, this year), Waldek?
Frank
Frank Heckenbach wrote:
Well, my next bigger changes in GPC according to my plans were going to be the preprocessor and then short strings, but perhaps I should change my priorities now. I suppose the preprocessor is still urgent, as it makes GPC more or less difficult to use (depending on the platform) with gcc-3.3.x and higher. But as I understand it, you have work-arounds for short strings, so perhaps classes are more urgent then.
I vote for short strings, but I can only speak for myself.
Regards,
Adriaan van Os
On 9 Jun 2005 at 14:39, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Most of these changes are implicit in Delphi-style "Classes", which I believe, are on the GPC "to do" list. Once GPC gets the "Class" type, there will be no need to do any of these. So I guess what you are pushing for is a quick implementation of Classes. I am not sure myself that this would be a trivial undertaking. However, I'll leave Frank and Waldek to speak to that point.
Certainly not trivial, and in addition, all of Mac, Delphi and OOE objects/classes are slightly different.
Well, my next bigger changes in GPC according to my plans were going to be the preprocessor and then short strings, but perhaps I should change my priorities now. I suppose the preprocessor is still urgent, as it makes GPC more or less difficult to use (depending on the platform) with gcc-3.3.x and higher. But as I understand it, you have work-arounds for short strings, so perhaps classes are more urgent then.
I would think that Classes are more urgent. This is the last major hurdle to full Delphi compatibility. The absence of short strings can be worked around - but the absence of Classes cannot.
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku (The African Chief) wrote:
On 9 Jun 2005 at 14:39, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Most of these changes are implicit in Delphi-style "Classes", which I believe, are on the GPC "to do" list. Once GPC gets the "Class" type, there will be no need to do any of these. So I guess what you are pushing for is a quick implementation of Classes. I am not sure myself that this would be a trivial undertaking. However, I'll leave Frank and Waldek to speak to that point.
Certainly not trivial, and in addition, all of Mac, Delphi and OOE objects/classes are slightly different.
Well, my next bigger changes in GPC according to my plans were going to be the preprocessor and then short strings, but perhaps I should change my priorities now. I suppose the preprocessor is still urgent, as it makes GPC more or less difficult to use (depending on the platform) with gcc-3.3.x and higher. But as I understand it, you have work-arounds for short strings, so perhaps classes are more urgent then.
I would think that Classes are more urgent. This is the last major hurdle to full Delphi compatibility.
So are short strings to BP compatiblity.
The absence of short strings can be worked around - but the absence of Classes cannot.
I suppose they can -- by turning `class' into `object' and using explicit pointers. Not particularly nice, but neither are the short string work-arounds AFAICS.
Seems to be a matter of personal preference (or need). I'll keep thinking about it ...
Frank
On 9 Jun 2005 at 18:54, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
[...]
I would think that Classes are more urgent. This is the last major hurdle to full Delphi compatibility.
So are short strings to BP compatiblity.
Indeed. I guess wrapping up BP compatibility is more easily achieved than Delphi compatibility. For that reason, it may be the more worthwhile short-term target.
The absence of short strings can be worked around - but the absence of Classes cannot.
I suppose they can -- by turning `class' into `object' and using explicit pointers. Not particularly nice,
Not at all.
but neither are the short string work-arounds AFAICS.
I haven't found that to be a major problem. The absence of AnsiStrings is more of a problem IMO - but even that can be worked around.
Seems to be a matter of personal preference (or need). I'll keep thinking about it ...
Ok ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof A Olowofoyeku wrote:
On 9 Jun 2005 at 11:44, Peter N Lewis wrote:
With the recently announced move by Apple to convert the Mac platform over to Intel processors (at least initially still closed hardware, but with an Intel processor instead of a PowerPC) starting next year and completing the transition in 2007, the need for Pascal users to move from Metrowerks CodeWarrior Pascal to XCode/GPC (or FPC) is now much more immediate.
I presume since GCC can build a fat bundle application for both PPC and x86 that there will not be any problem with GPC doing that too.
So the primary problem that remains is the difference between Mac style objects and Borland style objects which we've discussed before. The primary requirement as I see it is the ability to write code where the use of the objects is source compatible (possibly using Macros if necessary), and the object definition has as few changes as possible, preferably also handled by macros.
As I see it, the minimal changes required are:
- Allow objectptr.field as a synonym for objectptr^.field
(currently this would be an error, so it is a relatively safe allowance)
- Allow type newobject = object(objectptr) ... end;
(currently this would be an error, so it is a relatively safe allowance)
I am not sure if we want such change for all objects, since it reduces error checking and would allow quite strange mixture of dialects. We probably do not want things like:
o^.m; o.m;
Support the "override" keyword and add a compiler flag to require it.
Add a compiler flag to disable the "virtual" keyword and make all
methods virtual by default.
- Preferably add a compiler flag to say "objects are pointers" which
simply adds an implicit pointer reference to the object type definition, ie:
type myobject = object(superobject) ... end;
implicitly becomes
type myobject = ^object(superobject) ... end;
Without this change, but with the other changes, the user could change the object definition from:
type myobject = object(superobject) ... end;
to
type myobject = ^myrealobject; myrealobject = object(superobject) ... end;
[...]
Most of these changes are implicit in Delphi-style "Classes", which I believe, are on the GPC "to do" list. Once GPC gets the "Class" type, there will be no need to do any of these. So I guess what you are pushing for is a quick implementation of Classes. I am not sure myself that this would be a trivial undertaking. However, I'll leave Frank and Waldek to speak to that point.
I have started implementation of Delphi classes. I was able to compile a few simple test programs. I did that around Christmas, so the code needs updating to current gpc version. I plan to do some more work on it after the next gpc alpha.
However, note that `Delphi classes' (and `Apple objects') actually is a colletion of features. As long as we have only subset of features using old code requires a lot of work. ATM I am trying to implement bare essentials, to allow writing "blended code", which works with both GPC and Delphi and looks reasonable. Internally I convert class definition into pointer to object definition. Also I implemented auto-dereferencing for pointers representing classes. But even essentials require more then one naively expects: in my first trial there was no way to create a Delphi class (so I had to hack new to create them). IIRC I still have to correct calling constructors.
Concening Mac Pascal: IIUC the most visible difference is that Delphi uses the keyword `class' while Mac Pascal uses just `object'. That can be handled by a macro (of course, the `class' is then a reserved word). In principle we could handle it also via dialect flag. Then dialect flag could also make all methods virtual. But that would be a biggest difference in code generation triggered via dialect flag.
At 3:22 +0200 13/6/05, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
On 9 Jun 2005 at 11:44, Peter N Lewis wrote:
- Allow type newobject = object(objectptr) ... end;
(currently this would be an error, so it is a relatively safe allowance)
I am not sure if we want such change for all objects, since it reduces error checking and would allow quite strange mixture of dialects. We probably do not want things like:
o^.m; o.m;
Personally I don't see any problem with that. Once you accept that Objects are pointers, then you accept that o.m is really just shorthand for o^.m
But certainly it is worth a compiler flag or two to control it, with options along the lines of:
Requite explicit object pointer dereference (Delphi default) Disallow explicit object pointer dereference (Mac default) Either is acceptable (GPC default)
Support the "override" keyword and add a compiler flag to require it.
Add a compiler flag to disable the "virtual" keyword and make all
methods virtual by default.
Actually, thinking about it for a bit longer, these two would actually be the most useful. Everything else is a simple syntactic change. If I was going to convert my code entirely to GPC (which I now have to seriously consider given CodeWarrior will almost certainly never support Mac OS X/Intel), then it is just a matter of adding ^ before all the dots in object method calls. But the difference between "methods are always virtual, and override is required" and "methods are static by default, and you can override blindly" is a high level conceptual change which could result in a lot of confusion and bugs (the syntax changes either compiler and are right, or dont compile and are wrong, which is much more pleasant!).
I wonder how hard it would be to support a flag to require the "override" keyword and to make methods virtual by default?
Given that I would seriously consider changing to using explicit pointers.
However, note that `Delphi classes' (and `Apple objects') actually is a colletion of features. As long as we have only subset of features using old code requires a lot of work. ATM I am trying to implement bare essentials, to allow writing "blended code", which works with both GPC and Delphi and looks reasonable. Internally I convert class definition into pointer to object definition. Also I implemented auto-dereferencing for pointers representing classes. But even essentials require more then one naively expects: in my first trial there was no way to create a Delphi class (so I had to hack new to create them). IIRC I still have to correct calling constructors.
Mac Objects are created with New, disposed with Dispose, and have no constructor/destructor support.
Concening Mac Pascal: IIUC the most visible difference is that Delphi uses the keyword `class' while Mac Pascal uses just `object'. That can be handled by a macro (of course, the `class' is then a reserved word). In principle we could handle it also via dialect flag. Then dialect flag could also make all methods virtual. But that would be a biggest difference in code generation triggered via dialect flag.
I'm not familiar with Delphi objects, but what you say sounds about correct. I don't see any problem with a dialect flag that triggers a fairly large code generation change, since the whole point of this is to make the code generation match the dialect. And in this case, at least if I understand it, the code generation could be identical with or without the flag if the "virtual" keyword is pasted after the end of every method definition, right?
Also, if you think about it, compiler flags that affect optimization or rancg checking have a much more widespread affect on generated code.
Enjoy, Peter.
Peter N Lewis wrote:
At 3:22 +0200 13/6/05, Waldek Hebisch wrote:
Prof A Olowofoyeku wrote:
On 9 Jun 2005 at 11:44, Peter N Lewis wrote:
- Allow type newobject = object(objectptr) ... end;
(currently this would be an error, so it is a relatively safe allowance)
I am not sure if we want such change for all objects, since it reduces error checking and would allow quite strange mixture of dialects. We probably do not want things like:
o^.m; o.m;
Personally I don't see any problem with that. Once you accept that Objects are pointers, then you accept that o.m is really just shorthand for o^.m
I think it's not very much in the spirit of Pascal. Either the dereference is implicit (like in `var' parameters if you will) or explicit, not both. IMHO usage should depend on how it was declared.
Requite explicit object pointer dereference (Delphi default)
I don't think so. AFAIK Delphi is implicit. You probably mean BP.
- Support the "override" keyword and add a compiler flag to require it.
This seems rather easy (at first glance).
- Add a compiler flag to disable the "virtual" keyword and make all
methods virtual by default.
We have that already.
Internally I convert class definition into pointer to object definition. Also I implemented auto-dereferencing for pointers representing classes.
BTW, Waldek, what about using REFERENCE_TYPE here? OTH, it should make automatic derefencing easy (we do that for `var' parameters and global variables of non-constant size), OTOH for classes, we do not always want to dererence (not on creation, possibly destruction (not sure off-hand), assignments, and parameter passing), so I'm not sure if it gains more than it hurts ...
But even essentials require more then one naively expects: in my first trial there was no way to create a Delphi class (so I had to hack new to create them). IIRC I still have to correct calling constructors.
Mac Objects are created with New, disposed with Dispose, and have no constructor/destructor support.
OOE and AFAIK Delphi objects do have them. Anyway, `New' for object references is still different enough from pointers. I expected those to be two of the more difficult areas.
Concening Mac Pascal: IIUC the most visible difference is that Delphi uses the keyword `class' while Mac Pascal uses just `object'. That can be handled by a macro (of course, the `class' is then a reserved word). In principle we could handle it also via dialect flag. Then dialect flag could also make all methods virtual. But that would be a biggest difference in code generation triggered via dialect flag.
I'm not familiar with Delphi objects, but what you say sounds about correct. I don't see any problem with a dialect flag that triggers a fairly large code generation change, since the whole point of this is to make the code generation match the dialect.
Well, so far, most dialect flags don't change code generation, or only in smaller ways (e.g., slightly different `mod' semantics). Most of them just dis-/allow features.
Anyway, we have at least four object models (BP, Delphi, OOE, Mac), and only two keywords (object, class, each used by two of them).
The question is if/how far we want to allow mixing of the models via inheritance. For the pointer/reference issue, we could probably say each type behaves according to the model it was declared, even if it inherits from other model's types. (Though we should check this can't lead to hidden problems.) For all-virtual-methods, we could either say Mac objects can only inherit from other objects if they (explicitly) have all methods virtual, or we don't require this so such a mixed object can have (inherited) non-virtual methods. I don't see a problem here at first glance, but again, should check more carefully.
Generally I'm also wary of letting code generation depend on compiler options (though currently we do with `--methods-always-virtual'). So perhaps we should make the four models in default mode available with four different syntaxes (either two other names besides object and class, or keyword combinations, such as `virtual object' (= Mac) ??? etc., just fantasizing, or using attributes, or whatever). Then a default mode program could use them all without compiler directives. The dialect options would then only switch syntax, so e.g., in Mac mode, `object' means `virtual object', and other object models are forbidden.
This is a bit similar with short strings, where I plan to have both EP and short strings available by default (probably as `String' and `String (n)' for EP and `ShortString' and `String[n]' for short strings), and dialect options would just flip the syntax.
Also, if you think about it, compiler flags that affect optimization or rancg checking have a much more widespread affect on generated code.
Not really. If the programs (WRT range-checking) and the compiler (WRT are optimization) are correct, the generated code will be equivalent.
Frank
Frank Heckenbach wrote:
Peter N Lewis wrote:
At 3:22 +0200 13/6/05, Waldek Hebisch wrote:
... snip ...
o^.m; o.m;
Personally I don't see any problem with that. Once you accept that Objects are pointers, then you accept that o.m is really just shorthand for o^.m
I think it's not very much in the spirit of Pascal. Either the dereference is implicit (like in `var' parameters if you will) or explicit, not both. IMHO usage should depend on how it was declared.
I agree with Frank. Pascal usually has exactly one way to access something, which follows from the logical construction of that something.
I agree with Frank. Pascal usually has exactly one way to access something, which follows from the logical construction of that something.
Umm, except for:
* Case variant records * Variables passed by reference (but still within scope) * Variables referenced by pointer * Optionally qualified variables
and no doubt there are quite a few other ways to access something by more than one method.
Frankly I don't care whether only one or the other is legal (as long as the appropriate one is legal for a given object technology), but I also don't see any need to restrict it, since for any object o, and any method m, o.m and o^.m unambiguously mean the same thing and cannot mean anything else, whether both are legal or not. Allowing both means one less compiler switch, except that a warning or error would be appropriate in some dialects - I just don't see any need for a warning for the GPC "subsume all" dialect.
Enjoy, Peter.
Peter N Lewis wrote:
I agree with Frank. Pascal usually has exactly one way to access something, which follows from the logical construction of that something.
Umm, except for:
- Case variant records
I don't understand this one. Variant record fields and selectors are accessed with `.', like normal records.
- Variables passed by reference (but still within scope)
- Variables referenced by pointer
- Optionally qualified variables
I think we're at cross purposes. Of course, there can be aliasing (which you refer to) which gives several ways to access something dynamically (e.g., the target of pointer a can be the same as the target of pointer-field b of record c). What Chuck and I mean is that each static access has a unique way (e.g., if a is a pointer, then to dereference the pointer one uses a^; which doesn't preclude that there may be other ways to get at that target such as c.b^; neither that `^' can have different meaning when applied to different things, such as file buffer access; neither that one can do other things with a without `^', such as c.b := a).
Frankly I don't care whether only one or the other is legal (as long as the appropriate one is legal for a given object technology), but I also don't see any need to restrict it, since for any object o, and any method m, o.m and o^.m unambiguously mean the same thing and cannot mean anything else, whether both are legal or not. Allowing both means one less compiler switch,
If you mean that doing this would eliminate the difference between BP and Mac objects, I don't think so. There are other cases which conflict more directly. E.g., assignments between objects copy the reference in Mac and Delphi (AFAIK), but copy the object itself in BP. So we need that difference anyway, and blurring it in some cases (where it might not be a direct conflict) seems to lead to a more confusing whole in the end ...
Frank
At 8:04 +0200 14/6/05, Frank Heckenbach wrote:
Peter N Lewis wrote:
I agree with Frank. Pascal usually has exactly one way to access something, which follows from the logical construction of that something.
Umm, except for:
- Case variant records
I don't understand this one. Variant record fields and selectors are accessed with `.', like normal records.
This is getting a bit far off topic now. But case variant records can generally have overlapping fields that are referenced by different names but which refer to the same location, akin to:
record case boolean of (true: a: UInt32); (false: b: SInt32); end;
(excuse me if I've got the syntax wrong, I didn't look it up and rarely use them).
Then r.a and r.b are two ways to access the same thing.
I seem to remember that GPC does not actually support this overlaying of memory, but it is fairly standard in traditional Pascals.
Frankly I don't care whether only one or the other is legal (as long as the appropriate one is legal for a given object technology), but I also don't see any need to restrict it, since for any object o, and any method m, o.m and o^.m unambiguously mean the same thing and cannot mean anything else, whether both are legal or not. Allowing both means one less compiler switch,
If you mean that doing this would eliminate the difference between BP and Mac objects, I don't think so. There are other cases which conflict more directly. E.g., assignments between objects copy the reference in Mac and Delphi (AFAIK), but copy the object itself in BP. So we need that difference anyway, and blurring it in some cases (where it might not be a direct conflict) seems to lead to a more confusing whole in the end ...
No, it would not eliminate the difference, and yes, you are correct, the assignment copies the pointer reference only, and so yes, there will be a blurring regardless, since under Mac Objects
o.a references a method o1 := o2 copies a reference to the object
and under BP Objects
o^.a references a method o1 := o2 copies the object
So if you're going to support both Mac/Delphi objects and BP objects, there is going to be some blurring. And the problematic area is the assignment, not the reference.
Regardless, this really is getting off topic and it really doesn't trouble me one way or the other how it is implemented or what is and isn't allowed (my only concern is the writing Mac objects is enabled, and even that I'm willing to do a fair amount of source changes as required). Peter.
Peter N Lewis wrote:
(my only concern is the writing Mac objects is enabled, and even that I'm willing to do a fair amount of source changes as required). Peter.
It is great to join the Mac developers with the Gnu developers.
But for this layperson, adapting Gnu to proprietary pascal seems backwards.
Further, pointers and pointers to pointers is abstract enough. Implicit and virtual goes over the top for all but a very few.
Add in the already confusing issues of incompatible types and packed records and my memory map seg faults :)
Rick.
Peter N Lewis wrote:
At 8:04 +0200 14/6/05, Frank Heckenbach wrote:
Peter N Lewis wrote:
I agree with Frank. Pascal usually has exactly one way to access something, which follows from the logical construction of that something.
Umm, except for:
- Case variant records
I don't understand this one. Variant record fields and selectors are accessed with `.', like normal records.
This is getting a bit far off topic now. But case variant records can generally have overlapping fields that are referenced by different names but which refer to the same location, akin to:
record case boolean of (true: a: UInt32); (false: b: SInt32); end;
(excuse me if I've got the syntax wrong, I didn't look it up and rarely use them).
Then r.a and r.b are two ways to access the same thing.
No, they aren't. A common misunderstanding.
I seem to remember that GPC does not actually support this overlaying of memory, but it is fairly standard in traditional Pascals.
GPC does it sometimes, other times not, for good reasons. The standards state explicitly that such usage is invalid.
Rick Engebretson wrote:
It is great to join the Mac developers with the Gnu developers.
But for this layperson, adapting Gnu to proprietary pascal seems backwards.
Well, we've been doing that since at least 1995 when Peter Gerwinski started adding Borland Pascal extensions ...
Further, pointers and pointers to pointers is abstract enough. Implicit and virtual goes over the top for all but a very few.
I suppose so. In the end they'll be happy if they can use their sources from other compilers unmodified as much as possiible. However, to get there, we have to discuss the difficult areas here, as we don't want to introduce several distinct and wholly incompatible modes.
CBFalconer wrote:
- Variables referenced by pointer
No such thing in standard Pascal. Pointers are only initialized by new.
Even then there can be aliases after pointer assignments.
- Optionally qualified variables
Again, what do you mean here?
Qualified imports (Extended Pascal).
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
- Variables referenced by pointer
No such thing in standard Pascal. Pointers are only initialized by new.
Even then there can be aliases after pointer assignments.
Copies, yes. I was referring to the bars against creating pointers to ordinary variables with all the attendent insecurities.
CBFalconer wrote:
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
- Variables referenced by pointer
No such thing in standard Pascal. Pointers are only initialized by new.
Even then there can be aliases after pointer assignments.
Copies, yes.
No, aliases. If you do:
var a, b: ^Integer;
begin New (a); b := a; end;
Then both a^ and b^ refer to the same target. The pointers are copies, but the target is identical. Note that ISO Pascal actually calls these targets "variables", so Peter's terminology was really correct according to ISO:
: 6.6.5.3 Dynamic allocation procedures new(p) : : shall create a new variable that is totally-undefined [...]
I was referring to the bars against creating pointers to ordinary variables with all the attendent insecurities.
Well, these insecurities are not bigger than dangling pointers. This can be easily proven. You might want to look up my discussions with Scott Moore in the newsgroups (some years ago) about this.
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
Copies, yes.
No, aliases. If you do:
var a, b: ^Integer;
begin New (a); b := a; end;
Then both a^ and b^ refer to the same target. The pointers are copies, but the target is identical. Note that ISO Pascal actually calls these targets "variables", so Peter's terminology was really correct according to ISO:
That's what I meant by "copies" (of pointers). Perfectly safe until one gets disposed. Often the only way of handling lists and the ilk.
CBFalconer wrote:
That's what I meant by "copies" (of pointers). Perfectly safe until one gets disposed. Often the only way of handling lists and the ilk.
Just like "address coined" pointers are perfectly safe until the pointed to variable goes out of scope. I know that ISO doesn't support it, and that you and Scott don't like it, but to convince me it's so evil, I need to hear better arguments. ;-)
Frank
Frank Heckenbach wrote:
Rick Engebretson wrote:
It is great to join the Mac developers with the Gnu developers.
But for this layperson, adapting Gnu to proprietary pascal seems backwards.
Well, we've been doing that since at least 1995 when Peter Gerwinski started adding Borland Pascal extensions ...
Further, pointers and pointers to pointers is abstract enough. Implicit and virtual goes over the top for all but a very few.
I suppose so. In the end they'll be happy if they can use their sources from other compilers unmodified as much as possiible. However, to get there, we have to discuss the difficult areas here, as we don't want to introduce several distinct and wholly incompatible modes.
Frank
Courtesy aside, ten variants of incompatible, incomplete pascal for the intel processor is absurd. That you can quote me on. Rick.
Rick Engebretson wrote:
I suppose so. In the end they'll be happy if they can use their sources from other compilers unmodified as much as possiible. However, to get there, we have to discuss the difficult areas here, as we don't want to introduce several distinct and wholly incompatible modes.
Courtesy aside, ten variants of incompatible, incomplete pascal for the intel processor is absurd. That you can quote me on. Rick.
Well, the Borland dialects surely are for the Intel processor. Mac Pascal (which started this thread) obviously not. So, which others?
Anyway, we didn't write those other compilers. We try to be compatible to some of them, yes. And sometimes this might be the only way for users of those dialects to continue to use their codebase on another system.
Of course, I hope they will change some dirty dialect features to more clean/standard ones in the long run. But this cannot easily be done in a short time (as when Apple now decides to change architectures). I can understand those concerns, having gone through it myself (coming from BP).
Frank
Well, the Borland dialects surely are for the Intel processor. Mac Pascal (which started this thread) obviously not. So, which others?
Mac is moving to Intel, so Mac Pascal will be fore Intel next year.
Anyway, we didn't write those other compilers. We try to be compatible to some of them, yes. And sometimes this might be the only way for users of those dialects to continue to use their codebase on another system.
Something that those of us with hundreds of thousands of lines of "Pascal" code in one of those dialects very much appreciate!
Of course, I hope they will change some dirty dialect features to more clean/standard ones in the long run. But this cannot easily be done in a short time (as when Apple now decides to change architectures). I can understand those concerns, having gone through it myself (coming from BP).
Indeed. It is always best to make one major change at a time, so for example, first move from the proprietary compiler to GPC, and then after that is working, then move from the proprietary language to Extended Pascal, presuming of course there is some benefit in doing that.
Enjoy, Peter.
Peter N Lewis wrote:
Well, the Borland dialects surely are for the Intel processor. Mac Pascal (which started this thread) obviously not. So, which others?
Mac is moving to Intel, so Mac Pascal will be fore Intel next year.
This part was about dialect features we're supporting. So far, there have been no new features for Mac Pascal on Intel AFAIK ;-), and if there will be, we'll have to decide whether/how to support them. (But if the makers of Mac Pascal compilers will find a need for new features on Intel, maybe they'd look at other compilers first, including perhaps GPC, to avoid spawning further new dialects ...)
Indeed. It is always best to make one major change at a time, so for example, first move from the proprietary compiler to GPC, and then after that is working, then move from the proprietary language to Extended Pascal, presuming of course there is some benefit in doing that.
Indeed. Or even, do major feature changes as single steps, say units to modules, short strings to EP strings, dirty variable sized arrays (this is for BP, don't know about Mac Pascal) to schemata, etc.
Frank
Peter N Lewis wrote:
I agree with Frank. Pascal usually has exactly one way to access something, which follows from the logical construction of that something.
Umm, except for:
- Case variant records
What do you mean here? CASE boolean OF ... ? There is still a prohibition, even if often not heeded, against accessing items that were not last written.
- Variables passed by reference (but still within scope)
Granted. References to input and output will often have this characteristic.
- Variables referenced by pointer
No such thing in standard Pascal. Pointers are only initialized by new.
- Optionally qualified variables
Again, what do you mean here?
and no doubt there are quite a few other ways to access something by more than one method.
bearing in mind that we (at least I) am talking about Standard or even Extended Pascal (ISO7185 or 10206).
Frank Heckenbach wrote:
Peter N Lewis wrote:
At 3:22 +0200 13/6/05, Waldek Hebisch wrote:
Internally I convert class definition into pointer to object definition. Also I implemented auto-dereferencing for pointers representing classes.
BTW, Waldek, what about using REFERENCE_TYPE here? OTH, it should make automatic derefencing easy (we do that for `var' parameters and global variables of non-constant size), OTOH for classes, we do not always want to dererence (not on creation, possibly destruction (not sure off-hand), assignments, and parameter passing), so I'm not sure if it gains more than it hurts ...
I tried REFERENCE_TYPE first and immediatly hit problems. It looks easier (and safer) explicitly handle few places where we do have to autodereference than to undo what REFERENCE_TYPE is doing. In particular, it was easy to forbid unwanted autodereference.
But even essentials require more then one naively expects: in my first trial there was no way to create a Delphi class (so I had to hack new to create them). IIRC I still have to correct calling constructors.
Mac Objects are created with New, disposed with Dispose, and have no constructor/destructor support.
OOE and AFAIK Delphi objects do have them. Anyway, `New' for object references is still different enough from pointers. I expected those to be two of the more difficult areas.
I would like to see real examples of Mac Objects. What Peter writes suggest that Mac Pascal uses plain New. The question is how one can create child objects. Delphi allows:
type o1 = class end; o2 = class(o1) end;
var vo : o1; begin vo := o1.Create end;
Does one have to use intermediate variable to create child object in Mac Pascal?
Anyway, we have at least four object models (BP, Delphi, OOE, Mac), and only two keywords (object, class, each used by two of them).
ATM I do not noticed serious incompatibility between Delphi and OOE: Delphi looks just like an extension of OOE subset (compatible with full OOE).
The question is if/how far we want to allow mixing of the models via inheritance. For the pointer/reference issue, we could probably say each type behaves according to the model it was declared, even if it inherits from other model's types. (Though we should check this can't lead to hidden problems.) For all-virtual-methods, we could either say Mac objects can only inherit from other objects if they (explicitly) have all methods virtual, or we don't require this so such a mixed object can have (inherited) non-virtual methods. I don't see a problem here at first glance, but again, should check more carefully.
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
Surely, such code could break some patterns valid in single-model programming, but people who want to stay in a single model may do it, and the others probably will find added complexity worthwile.
Generally I'm also wary of letting code generation depend on compiler options (though currently we do with `--methods-always-virtual'). So perhaps we should make the four models in default mode available with four different syntaxes (either two other names besides object and class, or keyword combinations, such as `virtual object' (= Mac) ??? etc., just fantasizing, or using attributes, or whatever). Then a default mode program could use them all without compiler directives. The dialect options would then only switch syntax, so e.g., in Mac mode, `object' means `virtual object', and other object models are forbidden.
I an not sure how Mac Pascal folks like `virtual object' but for me it looks fine.
Waldek Hebisch wrote:
I would like to see real examples of Mac Objects.
Have you seen peter5.pas? (But that's all I know, so Peter might want to provide further examples.)
Anyway, we have at least four object models (BP, Delphi, OOE, Mac), and only two keywords (object, class, each used by two of them).
ATM I do not noticed serious incompatibility between Delphi and OOE: Delphi looks just like an extension of OOE subset (compatible with full OOE).
Probably. I expect the least problems between those two.
The question is if/how far we want to allow mixing of the models via inheritance. For the pointer/reference issue, we could probably say each type behaves according to the model it was declared, even if it inherits from other model's types. (Though we should check this can't lead to hidden problems.) For all-virtual-methods, we could either say Mac objects can only inherit from other objects if they (explicitly) have all methods virtual, or we don't require this so such a mixed object can have (inherited) non-virtual methods. I don't see a problem here at first glance, but again, should check more carefully.
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
Surely, such code could break some patterns valid in single-model programming, but people who want to stay in a single model may do it, and the others probably will find added complexity worthwile.
Seems reasonable.
Generally I'm also wary of letting code generation depend on compiler options (though currently we do with `--methods-always-virtual'). So perhaps we should make the four models in default mode available with four different syntaxes (either two other names besides object and class, or keyword combinations, such as `virtual object' (= Mac) ??? etc., just fantasizing, or using attributes, or whatever). Then a default mode program could use them all without compiler directives. The dialect options would then only switch syntax, so e.g., in Mac mode, `object' means `virtual object', and other object models are forbidden.
I an not sure how Mac Pascal folks like `virtual object' but for me it looks fine.
In Mac Pascal mode, `object' would do the same; perhaps we should add a separate option `--object-model=mac' or something; and as a last resort, a {$define} will do.
Frank
On 18 Jun 2005 at 19:57, Frank Heckenbach wrote:
Waldek Hebisch wrote:
[...]
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
Surely, such code could break some patterns valid in single-model programming, but people who want to stay in a single model may do it, and the others probably will find added complexity worthwile.
Seems reasonable.
Is it possible to achieve inheritance from C++ objects?
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Prof. Abimbola A. Olowofoyeku wrote:
On 18 Jun 2005 at 19:57, Frank Heckenbach wrote:
Waldek Hebisch wrote:
[...]
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
Surely, such code could break some patterns valid in single-model programming, but people who want to stay in a single model may do it, and the others probably will find added complexity worthwile.
Seems reasonable.
Is it possible to achieve inheritance from C++ objects?
I think so. Hard, but should be doable by re-using parts of C++ compiler.
There are nasty semantic problems: -- C++ names are case-sensitive -- C++ methods may be overloaded -- C++ methods may be inline -- templates
Still, there is Objective-C++ compiler which allows mixing Objective C with C++, so the problems are solvable.
Waldek Hebisch wrote:
Prof. Abimbola A. Olowofoyeku wrote:
On 18 Jun 2005 at 19:57, Frank Heckenbach wrote:
Waldek Hebisch wrote:
[...]
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
Surely, such code could break some patterns valid in single-model programming, but people who want to stay in a single model may do it, and the others probably will find added complexity worthwile.
Seems reasonable.
Is it possible to achieve inheritance from C++ objects?
I think so. Hard, but should be doable by re-using parts of C++ compiler.
There are nasty semantic problems: -- C++ names are case-sensitive -- C++ methods may be overloaded -- C++ methods may be inline -- templates
Still, there is Objective-C++ compiler which allows mixing Objective C with C++, so the problems are solvable.
I think overloading and inlining are things some here want to see anyway. Case-sensitive names are a problem, as always, but probably solvable similar to C names (perhaps using attributes etc.). IMHO templates are somewhat orthogonal, so perhaps we should leave them out (at first).
What about friends (maybe not a big problem), multiple inheritance, etc.? As I understand it, the virtual method calling mechanism is different because of multiple inheritance, possibly less efficent (is it?). If so, I'm a bit doubtful of changing it in GPC (at least, unconditionally), and we surely won't get it changed in G++ ...
Frank
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Prof. Abimbola A. Olowofoyeku wrote:
On 18 Jun 2005 at 19:57, Frank Heckenbach wrote:
Waldek Hebisch wrote:
[...]
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
Surely, such code could break some patterns valid in single-model programming, but people who want to stay in a single model may do it, and the others probably will find added complexity worthwile.
Seems reasonable.
Is it possible to achieve inheritance from C++ objects?
I think so. Hard, but should be doable by re-using parts of C++ compiler.
There are nasty semantic problems: -- C++ names are case-sensitive -- C++ methods may be overloaded -- C++ methods may be inline -- templates
Still, there is Objective-C++ compiler which allows mixing Objective C with C++, so the problems are solvable.
I think overloading and inlining are things some here want to see anyway. Case-sensitive names are a problem, as always, but probably solvable similar to C names (perhaps using attributes etc.). IMHO templates are somewhat orthogonal, so perhaps we should leave them out (at first).
Yes.
What about friends (maybe not a big problem), multiple inheritance, etc.? As I understand it, the virtual method calling mechanism is different because of multiple inheritance, possibly less efficent (is it?). If so, I'm a bit doubtful of changing it in GPC (at least, unconditionally), and we surely won't get it changed in G++ ...
I did not look at details of C++ method. But my impression is that there is no extra overhead when using only single inheritance. AFAICS OOP and Delphi already have multiple inheritance. Like Java it is limited to interfaces, but still it brings similar problems. So adapting C++ model my be the easiest way to implement OOP.
Concerning friends, IMHO we can ignore them. If we imlement (import) C++ ABI then C++ friends will work.
Waldek Hebisch wrote:
Prof. Abimbola A. Olowofoyeku wrote:
On 18 Jun 2005 at 19:57, Frank Heckenbach wrote:
Waldek Hebisch wrote:
[...]
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
Surely, such code could break some patterns valid in single-model programming, but people who want to stay in a single model may do it, and the others probably will find added complexity worthwile.
Seems reasonable.
Is it possible to achieve inheritance from C++ objects?
I think so. Hard, but should be doable by re-using parts of C++ compiler.
There are nasty semantic problems: -- C++ names are case-sensitive -- C++ methods may be overloaded -- C++ methods may be inline -- templates
Still, there is Objective-C++ compiler which allows mixing Objective C with C++, so the problems are solvable.
It all depends upon what you mean by "mixing". If you mean mixing as in being able to have Objective C objects and C++ objects being defined and used in the same program and source code - yep, you can do that. If mean mixing as in Objective C objects inheriting from C++ objects and vice versa - nope.
Gale Paeper gpaeper@empirenet.com
On 19 Jun 2005 at 1:50, Waldek Hebisch wrote:
[...]
Is it possible to achieve inheritance from C++ objects?
I think so. Hard, but should be doable by re-using parts of C++ compiler.
If it can be done in such a way that will not require constant re- engineering with each new gcc release, then it would be a very nice thing to have.
There are nasty semantic problems: -- C++ names are case-sensitive
This can hopefully be solved by using attributes, as Frank suggested. If not, then it is a limitation that I will be very happy to live with if it means being able to use C++ objects (which would still be a great improvement over the current situation). It would mean that things like wxWidgests would be usable with GPC for example.
-- C++ methods may be overloaded
As are Delphi Class methods (since Delphi 4.0 (released in 1998) I believe).
-- C++ methods may be inline
Don't know much about this ...
-- templates
Ditto ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.greatchief.plus.com/
Waldek Hebisch wrote:
I would like to see real examples of Mac Objects.
Peter can best answer this question.
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
CW Pascal can not do this, but it would be a superb feature - interfacing directly with C++ and Objective C objects (e.g. GNU Step/Cocoa and Qt and many more OOP frameworks which we are more and more forced to work with).
Regards,
Adriaan van OS
Adriaan van OS wrote:
Waldek Hebisch wrote:
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
CW Pascal can not do this, but it would be a superb feature - interfacing directly with C++ and Objective C objects (e.g. GNU Step/Cocoa and Qt and many more OOP frameworks which we are more and more forced to work with).
Well, so what is:
http://pascal-central.com/cwpascal.html
describing?
Waldek Hebisch wrote:
Adriaan van OS wrote:
Waldek Hebisch wrote:
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
CW Pascal can not do this, but it would be a superb feature - interfacing directly with C++ and Objective C objects (e.g. GNU Step/Cocoa and Qt and many more OOP frameworks which we are more and more forced to work with).
Well, so what is:
http://pascal-central.com/cwpascal.html
describing?
I am flabbergasted ... Maybe Peter or Gale can shed some light on it. Was this ever implemented ?
Regards,
Adriaan van Os
Waldek Hebisch wrote:
Adriaan van OS wrote:
Waldek Hebisch wrote:
I think that letting an object inherit from anything should work. In fact, one of my pet ideas is to let Pascal objects inherit from other language objects and vice-versa. AFAICS inheriting from Objective C objects is one of main CW Pascal extensions.
CW Pascal can not do this, but it would be a superb feature - interfacing directly with C++ and Objective C objects (e.g. GNU Step/Cocoa and Qt and many more OOP frameworks which we are more and more forced to work with).
Well, so what is:
http://pascal-central.com/cwpascal.html
describing?
Although it isn't clear from the text, it is describing *proposed* extensions. Some of the proposals got implemented in the compiler to some extent and others didn't.
Section 2, "Extensions providing compatibility with Objective C", of that document was never implemented.
The outcome for the section 1 is something of a mixed bag of some fully implemented, some partially implemented, and some never implemented.
Visibility of data fields - Implemented but the default visibility is public not protected as stated in the document.
Class declaration layout and Class forward declarations - I think those were implemented as stated but I've never done any eplicit testing to verifiy it.
Return directive - Implemented.
Anonymous types - I don't think it got implemented. I've never seen or heard of anything indicating it was, but I haven't tried any blackbox compiler testing to see if some sort of support for this actual got implemented in the last compiler(s).
Schemata - Implemented but the implementation is just a subset of what Extended Pascal requires for dynamic and schemata types.
Unit initialization - I suppose sort of implemented is about the best way to charaterize the status of that one. The compiler accepts the initialization code and generates the object code for it but there is some critical piece missing which stops it from getting tied in to the final executeable.
Complex data type - Not implemented.
In the interest of fairness, I'll note in closing that at the time "Extensions to CodeWarrior Pascal" was published, the Metrowerks Pascal compiler engineers (or so I believe) had every intent of fully implementing the described extensions. Unfortunately, corporate priorities and resource alloctations changed before the engineers could complete the work involved.
Gale Paeper gpaeper@empirenet.com
Adriaan van Os wrote:
Waldek Hebisch wrote:
I would like to see real examples of Mac Objects.
Peter can best answer this question.
Anyway, here is a complete example http://www.pascal-central.com/cwport.html.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Waldek Hebisch wrote:
I would like to see real examples of Mac Objects.
Peter can best answer this question.
Anyway, here is a complete example http://www.pascal-central.com/cwport.html.
Sorry - I now see that the link is of little use (the package is incomplete and you would need a Mac to process the diff). I am sending a complete example by private email.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Adriaan van Os wrote:
Waldek Hebisch wrote:
I would like to see real examples of Mac Objects.
Peter can best answer this question.
Anyway, here is a complete example http://www.pascal-central.com/cwport.html.
Sorry - I now see that the link is of little use (the package is incomplete and you would need a Mac to process the diff). I am sending a complete example by private email.
Thanks for the example. To say the truth, I was hoping for something with less Mac OS dependencies, but showing how Mac Objects are used. ATM I noticed only one feature (objects are declared in TCL unit, but methods are implemented in different units) which is not present in `peter5.pas'. But with so many Mac OS dependencies it is hopeless to try to compile TCL on Linux.
Waldek Hebisch wrote:
Frank Heckenbach wrote:
[snip]
Generally I'm also wary of letting code generation depend on compiler options (though currently we do with `--methods-always-virtual'). So perhaps we should make the four models in default mode available with four different syntaxes (either two other names besides object and class, or keyword combinations, such as `virtual object' (= Mac) ??? etc., just fantasizing, or using attributes, or whatever). Then a default mode program could use them all without compiler directives. The dialect options would then only switch syntax, so e.g., in Mac mode, `object' means `virtual object', and other object models are forbidden.
I an not sure how Mac Pascal folks like `virtual object' but for me it looks fine.
Instead of special syntax and compiler options, I thinking some sort of predefined abstract root object type for each of the four object models which establishes and fixes the model characteristics of the object inheritance tree rooted on the respective predefined object model type might be the better way to handle supporting the different object models.
For example, the predefined object types could be:
TBPObject - establishes Turbo Pascal object model characteristics TDelphiClass - establishes Delphi class object model characteristics TMacObject - establishes MacPascal object model characteristics TOOEClass - establishes OOE class object model characteristics
For thrill seekers who are looking for a kitchen sink, does everything object model, you could add TGPCClass which (somehow) merges all the characteristics of the four other models into one superdooper model.
Note: I'm using TDelphiClass and TOOEClass as clarifying example names. Delphi does have TObject as a predefined root object that all classes inherits from and OOE has the predefined Root abstract object type which all user-defined concrete and abstract classes inherits from so those predefined identifiers would probably be best to use for implementation.
What I'm trying to cover with the model characteristics term is things like methods-always-virtual (for the OOE and MacPascal object models), instantance variables are always references and implicit dereferencing (for the Delphi, OOE, and MacPascal object models), instantiation/destruction using new/dispose or constructors/destructors, and all the other model specific features and quirks.
Since all four models are, in esense, single inheritance models, the compiler should always be able to determine an object entity's model characteristics by following the object ancestor type chain back to the anchoring root type and thus determine whether particular syntax construct is legal or illegal for the object entity. (I'm using entity as a generalizing term to cover things like object type(s) in type contexts and object instantances in instantances contexts.) (Also, I didn't forget about OOE's "mix-in" property class. But I don't think you need anything special to handle that since OOE property class aren't really a stand-alone object - they always have to hang off of OOE's single inheritance backbone.)
To handle the ambiguities of base class/object type declarations, i.e.:
type TExampleClass = class {...} end; TExampleObject = object {...} end;
the language dialect option would set the default predefined root which the base class or base object inherits from for the dialect specified by the option. For example, option --borland-pascal sets TBPObject as the default root for base object type declarations and there is no class support.
For the --gnu-pascal option where both object and class are supported, there isn't anything which preordains the defaults to use for object and class but the defaults chosen should at least try to pair up the object and class models having the most similarities. [TBPObject, TDelphiClass] or [TMacObject, TOOEClass] seem to me to be fairly good similarites pairings; however, if there is a superdooper model gnu-pascal extension, TGPCClass probably should the default for class part of the pair and TBPObject for the object part of the pair. To declare a base class or object type of a model different than the --gnu-pascal, just use explicit class/object inheritance to inherit from the predefined class/object with the desired model charateristics. For example:
type TExampleObject = object (TMacObject) {...} end;
would declare a base object type having MacPascal object model charateristics.
For all three the MacPascal dialect compilers, there is an ObjIntf.p unit file which declares TObject as a base object which by convention is generally used as psuedo-root object type for user defined object types. So, for MacPascal object Pascal porters that used the TObject convention in their object type declarations, a small change to the TObject declaration in the ObjIntf.p unit would be all that it takes to port MacPascal objects to GPC.
For the four predefined TBPObject, TDelphiClass, TMacObject, TOOEClass type, I don't think it is adviseable to try any sort of mixing. For those needing or wanting GPC support for one of those object models, I think the GPC capailities they want most is just to get a working implementation of the present model type capabilites and features.
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Instead of special syntax and compiler options, I thinking some sort of predefined abstract root object type for each of the four object models which establishes and fixes the model characteristics of the object inheritance tree rooted on the respective predefined object model type might be the better way to handle supporting the different object models.
I do not think so. The models have almost the same semantics (at least at low level), the differences are in syntax. More precisely, you can do essentially the same thing using any of the models, but you write them in different ways. "Inheriting" syntax would make programs much less readible: you would be forced to find root object to know what a given construct means (well, I typically have to look at the whole inheritance hierarchy to understand the code, but at least syntax does not change in unexpexted ways). My point is that it adds really silly non-local dependency to the code: if you chage root object than the changes propagate down the inheritance chains forcing re-writes for no good reason.
Note that the situation changes once we have support for binary incompatible object models. Then it makes sense for root object to fix the model (ABI). But IMHO not for syntax.
Waldek Hebisch wrote:
Gale Paeper wrote:
Instead of special syntax and compiler options, I thinking some sort of predefined abstract root object type for each of the four object models which establishes and fixes the model characteristics of the object inheritance tree rooted on the respective predefined object model type might be the better way to handle supporting the different object models.
I do not think so.
Me neither. I agree with Waldek's arguments. In addition pelase note that the BP model doesn't have one single root object, and it's common (at least for some programmers, including myself) to have various unrelated inheritance trees in a program. So one would have to specify "BP model" everywhere (in particular, as I don't compile with a BP options as I use many non-BP features otherwise).
Gale Paeper wrote:
For thrill seekers who are looking for a kitchen sink, does everything object model, you could add TGPCClass which (somehow) merges all the characteristics of the four other models into one superdooper model.
Unfortunately this seems impossible as in some respects the models conflict directly. E.g., are all methods virtual, or not? They can't both be and not be at the same time (in a "superdooper model"). So I think we need the distinction.
Delphi does have TObject as a predefined root object that all classes inherits from and OOE has the predefined Root abstract object type which all user-defined concrete and abstract classes inherits from so those predefined identifiers would probably be best to use for implementation.
AFAIK, several BP class libraries also use `TObject' (as a regular object type with no special properties). This would be conflicting or at least very confusing (e.g., when imported).
For the four predefined TBPObject, TDelphiClass, TMacObject, TOOEClass type, I don't think it is adviseable to try any sort of mixing. For those needing or wanting GPC support for one of those object models, I think the GPC capailities they want most is just to get a working implementation of the present model type capabilites and features.
But this would further support the balkanization of class libraries. I don't want GPC to become "N compilers in one" that N groups of programmers use in N different and incompatible ways, and in the end will implement each technique N times. Mixing of dialects has been a strength of GPC, and I'd like it to remain so with OOP.
For most other points, I agree with Gale, but in the end I think the advantages of mixing (by inheritance) outweigh.
Frank