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.