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