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.