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.