Prof A Olowofoyeku (The African Chief) wrote:
What you are describing is almost equal to the "new" style Delphi Classes (actually, this is already over 7 years old, so it is not so new - but I use "new" here to distinguish it from the original BP object model). That type of Delphi compatibility, is, I believe, on the to-do list - but perhaps not a high priority.
There is also the "Object-Oriented Extensions to Pascal" proposal, of the Technical Committee X3J9, see http://www.pascal-central.com/OOE-stds.html.
In passing, I have to mention that I personally prefer the BP object model, see section "E.6.5.1 The Object Model. ... The reference model has the following disadvantages: ...". Still, it is a given fact that traditional Macintosh Pascal compilers implemented the reference model.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
What you are describing is almost equal to the "new" style Delphi Classes (actually, this is already over 7 years old, so it is not so new - but I use "new" here to distinguish it from the original BP object model). That type of Delphi compatibility, is, I believe, on the to-do list - but perhaps not a high priority.
There is also the "Object-Oriented Extensions to Pascal" proposal, of the Technical Committee X3J9, see http://www.pascal-central.com/OOE-stds.html.
I have heard that this is quite similar to Delphi's model. (I can only hope that's true, otherwise we might have 4 object models ...)
In passing, I have to mention that I personally prefer the BP object model, see section "E.6.5.1 The Object Model. ... The reference model has the following disadvantages: ...". Still, it is a given fact that traditional Macintosh Pascal compilers implemented the reference model.
We surely won't remove the BP model.
Frank
On 16 Jul 2003 at 17:08, Frank Heckenbach wrote:
Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
What you are describing is almost equal to the "new" style Delphi Classes (actually, this is already over 7 years old, so it is not so new - but I use "new" here to distinguish it from the original BP object model). That type of Delphi compatibility, is, I believe, on the to-do list - but perhaps not a high priority.
There is also the "Object-Oriented Extensions to Pascal" proposal, of the Technical Committee X3J9, see http://www.pascal-central.com/OOE-stds.html.
I have heard that this is quite similar to Delphi's model. (I can only hope that's true, otherwise we might have 4 object models ...)
It is extremely similar to Delphi's model, with specific extensions to EP being proposed as well.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Frank Heckenbach wrote:
Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
What you are describing is almost equal to the "new" style Delphi Classes (actually, this is already over 7 years old, so it is not so new - but I use "new" here to distinguish it from the original BP object model). That type of Delphi compatibility, is, I believe, on the to-do list - but perhaps not a high priority.
There is also the "Object-Oriented Extensions to Pascal" proposal, of the Technical Committee X3J9, see http://www.pascal-central.com/OOE-stds.html.
I have heard that this is quite similar to Delphi's model. (I can only hope that's true, otherwise we might have 4 object models ...)
Although there are quite a few similarities between Delphi and OOE, there are some significant differences which I don't think can be handled in the same object model. For example, Delphi's object model is single inheritance only whereas OOE provides for a limited form of multiple inheritance with the mix-in type property class. Unfortunately, Borland choose to use the property word-symbol for a different feature (which isn't in OOE) so there is a clash in word-symbol useage between the two.
As far a model similarities go, there is a closer similarity between the Mac object mode and OOE's object model than there is between Delphi's and OOE's object models. In many aspects, you could view OOE's object model (and language extensions) as the much improved version 2 of Apple's version 1 Mac Object Pascal which was created in consultation with Wirth in the 1984/85 time period. (If GPC already had the planned for support for OOE, I don't think there would be any need to worry about supporting a separate Mac object model. Although there are a few differences, the differences are relatively minor and could be easily handled with a relatively few conditional compilation directives to handle the object versus class key-word syntax and new/dispose versus constructor/destructor methods for object instantiation and destruction.)
In passing, I have to mention that I personally prefer the BP object model, see section "E.6.5.1 The Object Model. ... The reference model has the following disadvantages: ...". Still, it is a given fact that traditional Macintosh Pascal compilers implemented the reference model.
To gain a more balanced assessment between the two models, one also needs to see section "D.1 Record Extensions ... The value model has many disadvantages ...".
Gale Paeper gpaeper@empirenet.com
Gale Paeper wrote:
Frank Heckenbach wrote:
Adriaan van Os wrote:
Prof A Olowofoyeku (The African Chief) wrote:
What you are describing is almost equal to the "new" style Delphi Classes (actually, this is already over 7 years old, so it is not so new - but I use "new" here to distinguish it from the original BP object model). That type of Delphi compatibility, is, I believe, on the to-do list - but perhaps not a high priority.
There is also the "Object-Oriented Extensions to Pascal" proposal, of the Technical Committee X3J9, see http://www.pascal-central.com/OOE-stds.html.
I have heard that this is quite similar to Delphi's model. (I can only hope that's true, otherwise we might have 4 object models ...)
Although there are quite a few similarities between Delphi and OOE, there are some significant differences which I don't think can be handled in the same object model. For example, Delphi's object model is single inheritance only whereas OOE provides for a limited form of multiple inheritance with the mix-in type property class. Unfortunately, Borland choose to use the property word-symbol for a different feature (which isn't in OOE) so there is a clash in word-symbol useage between the two.
OK, so there are differences, but not necessarily conflicts. The two uses of `property' seem to be in sufficiently different contexts, so they won't conflict. (In the usual way we do things, GPC would then allow both by default and check for the respective dialect options.)
As far a model similarities go, there is a closer similarity between the Mac object mode and OOE's object model than there is between Delphi's and OOE's object models. In many aspects, you could view OOE's object model (and language extensions) as the much improved version 2 of Apple's version 1 Mac Object Pascal which was created in consultation with Wirth in the 1984/85 time period. (If GPC already had the planned for support for OOE, I don't think there would be any need to worry about supporting a separate Mac object model. Although there are a few differences, the differences are relatively minor and could be easily handled with a relatively few conditional compilation directives to handle the object versus class key-word syntax
It may seem minor to you, but in fact this one may be a real conflict (because the same code may mean different things in BP and Mac Pascal).
So obviously we have different metrics. For me, two things having similar or identical syntax and different semantics is quite a bit worse than different syntax and semantics. The latter may be more work to implement it all (but not necessarily), but the former probably means in the end we can only support one or make the result dependent on the dialects. This is always unfortunate (i.e., if the dialect options are not only about whether something is accepted or not, but it's accepted with different meanings; we have such examples, e.g., the `mod' semantics with negative arguments, or the precedence of unary `+' and `-') ...
In passing, I have to mention that I personally prefer the BP object model, see section "E.6.5.1 The Object Model. ... The reference model has the following disadvantages: ...". Still, it is a given fact that traditional Macintosh Pascal compilers implemented the reference model.
To gain a more balanced assessment between the two models, one also needs to see section "D.1 Record Extensions ... The value model has many disadvantages ...".
I tend to disagree:
: + The absence of object identity;
I think this only applies if you allow for object assignments and value parameters. They're part of BP objects indeed, but I find that this object model works well without them. In fact, I haven't implemented them in GPC until a few weeks ago (after the last release), and except maybe for a few rare cases, I don't think anyone has missed them very much. (I haven't needed them in all my code.) In the future, GPC will still warn about them (except in --borland-pascal), so it may be reasonable to talk about the model without copying objects.
: + The absence of complete polymorphism, which is provided only via : pointers and reference parameters;
Which is the normal thing to do (just like, e.g., with Pascal files where it's even required because files must have an identity).
: + An increased dependency between modules; (Modules that have : allocated static records, or that use the size of a record for : allocating storage on the stack, need to be recompiled if the size : of the record changes.)
That's entirely an implementation detail. In GPC, e.g., an importer must be recompiled if a virtual method is inserted/removed/moved. Although this doesn't influence the size of the object, it does change the offsets used internally. Generally, an importer must be recompiled whenever an imported interface changes. (And since usually methods change more often than fields do, I think the disadvantage described above is rather rare/academic.)
: + A more complex model with many nuances involving constructors, : destructors,
I'm not sure if it's really more complex. To me (of course I'm used to it) it seems quite logical, at least more in line with standard Pascal syntax: Dynamic objects are allocated explicitly with `New' and deallocated with `Dispose', just like any other types, and the con-/destructor calls are inserted there. Whereas in the OOE model, constructors are called like functions (although they're declared like procedures, i.e. without result types), and the creation of the object happens somehow "magically" when a new object is created (but not when an inherited constructor is called).
: + A requirement to specify conceptually unnecessary dereferencing;
Unnecessary, depends. Again, I think it's more in line with Pascal's typing in general.
It may be a little easier to use with implicit references, but then the same should probably apply to files (removing the special exceptions that files may only be passed by reference, not returned and assigned).
In summary I think, the OOE model may be a little more practical by itself, but the BP model seems to fit better to Pascal (and that's me, talking about Borland, strange ... ;-).
In hindsight, Wirth might have done a few things differently in Pascal (e.g. files as mentioned, also `endif' maybe). But Pascal being like it is, I doubt whether the OOE model is the best fit for the language ...
This doesn't mean that I'll never implement it, but those problematic differences described above probably also mean extra contortions in the compiler, and therefore more work to implement it, so it not be soon.
As for the implicit object pointer dereferencing, I'm still waiting to decide whether it's useful to do it with pointers to (existing) objects, or if not a distinct object reference type will be necessary anyway (so it wouldn't make much sense to klduge it now with object pointers).
Frank
On 21 Jul 2003 at 18:32, Frank Heckenbach wrote:
[...]
As for the implicit object pointer dereferencing, I'm still waiting to decide whether it's useful to do it with pointers to (existing) objects, or if not a distinct object reference type will be necessary anyway (so it wouldn't make much sense to klduge it now with object pointers).
Please don't do it with plain old BP objects (except perhaps when the Mac defines are turned on). As you said, a reference type will be necessary anyway. Anyone who wants the implicit dereferencing can use the new object type when it is implemented. IMHO the BP object model should be kept intact, since it is now a lowest common denominator for many Pascal compilers.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
At 9:44 +0100 22/7/03, Prof. A Olowofoyeku (The African Chief) wrote:
As for the implicit object pointer dereferencing, I'm still waiting to decide whether it's useful to do it with pointers to (existing) objects, or if not a distinct object reference type will be necessary anyway (so it wouldn't make much sense to klduge it now with object pointers).
Please don't do it with plain old BP objects (except perhaps when the Mac defines are turned on). As you said, a reference type will be necessary anyway. Anyone who wants the implicit dereferencing can use the new object type when it is implemented. IMHO the BP object model should be kept intact, since it is now a lowest common denominator for many Pascal compilers.
As mentioned, all that is minimally required is allowing (with an option turned on)
objectptr.field as a synonym for objectptr^.field
Since otherwise the former code will simply give an error, there should be no compatibility problems for existing code or code written to the existing BP standard.
And extra nicety would be to allow:
type newobject = object(objectptr) ... end;
which again would otherwise simply be an error.
With these two, it would be relatively trivial to write compatible code, the only changes needed would be:
type myobject = object(superobject) ... end;
converts to type myobject = ^myrealobject; myrealobject = object(superobject) ... end;
(that would be the final nicety, but would be incompatible semantics for compatible syntax).
I think after that everything would "just work", since:
var o: myobject; new(o);
would be unchanged, as would dispose(o) and o.method or o.variable
This seems relatively simple, very safe, and within the GPC's goal of being a super set of all Pascals without introducing incompatible semantics for compatible syntax.
Enjoy, Peter.
Peter N Lewis wrote:
At 9:44 +0100 22/7/03, Prof. A Olowofoyeku (The African Chief) wrote:
As for the implicit object pointer dereferencing, I'm still
waiting to
decide whether it's useful to do it with pointers to (existing) objects, or if not a distinct object reference type will be necessary anyway (so it wouldn't make much sense to klduge it now with object pointers).
Please don't do it with plain old BP objects (except perhaps when the Mac defines are turned on). As you said, a reference type will be necessary anyway. Anyone who wants the implicit dereferencing can use the new object type when it is implemented. IMHO the BP object model should be kept intact, since it is now a lowest common denominator for many Pascal compilers.
As mentioned, all that is minimally required is allowing (with an option turned on)
objectptr.field as a synonym for objectptr^.field
Since otherwise the former code will simply give an error, there should be no compatibility problems for existing code or code written to the existing BP standard.
And extra nicety would be to allow:
type newobject = object(objectptr) ... end;
which again would otherwise simply be an error.
With these two, it would be relatively trivial to write compatible code, the only changes needed would be:
type myobject = object(superobject) ... end;
converts to type myobject = ^myrealobject; myrealobject = object(superobject) ... end;
(that would be the final nicety, but would be incompatible semantics for compatible syntax).
I think after that everything would "just work", since:
var o: myobject; new(o);
would be unchanged, as would dispose(o) and o.method or o.variable
This seems relatively simple, very safe, and within the GPC's goal of being a super set of all Pascals without introducing incompatible semantics for compatible syntax.
As long as Peter's proposal is an option that can be turned on and off, I think everybody can be perfectly happy with it. I suggest that the option is turned off by default, except for --mac-pascal (and maybe for --delphi).
Regards,
Adriaan van Os
Peter N Lewis wrote:
As mentioned, all that is minimally required is allowing (with an option turned on)
objectptr.field as a synonym for objectptr^.field
And extra nicety would be to allow:
type newobject = object(objectptr) ... end;
With these two, it would be relatively trivial to write compatible code, the only changes needed would be:
type myobject = object(superobject) ... end;
converts to type myobject = ^myrealobject; myrealobject = object(superobject) ... end;
(that would be the final nicety, but would be incompatible semantics for compatible syntax).
I think after that everything would "just work", since:
var o: myobject; new(o);
would be unchanged, as would dispose(o) and o.method or o.variable
This seems relatively simple, very safe, and within the GPC's goal of being a super set of all Pascals without introducing incompatible semantics for compatible syntax.
I'm still undecided whether it's better to extend BP objects in this way, or make a separate kind of objects which have those properties. The latter will be more work initially, but depending on what will be required later, it might be better to distinguish them. So I think I need more complete information about the Mac objects, compared to GPC's objects. Up to now we have:
1. Object types are pointers
2. Those pointers are implicitly dereferenced
[3. All methods are virtual -- done in the next release, by `--methods-always-virtual', on by default in `--mac-pascal']
[4. No constructors/destructors -- done, by not recognizing `constructor' and `destructor' as keywords in `--mac-pascal]
What else?
E.g., a test program Peter sent me contained `override' which hadn't been mentioned here so far. So please (all who use Mac Pascal) check carefully if there are any more differences because they might influence the implementation.
BTW, about `override': I'm not quite sure I really understand it (also after looking in OOE). Does it do the same as BP/GPC methods without any special directive which happen to override an inherited method? What happens (in MP/OOE) if a method of the same name as an inherited methods is not declared `override', is it just an error? (Or if an `override' method does not actually override?) IOW, is there actually any behaviour (with or without this directive) that doesn't correspond to BP, or is it just different syntax?
BTW, does MP have `virtual'? Otherwise we should disable this keyword in `--mac-pascal', shouldn't we?
BTW, A quick idea for the object pointers: If we allow `Parent' in `type Foo = object (Parent)' to be an object pointer type, it *may* (still doubtful) be useful to make `Foo' a pointer as well. This way the syntactic difference would be limited to the root object types. This would be particularly useful if there's (by convention or requirement) only one root object type (presumable in a standard unit then), so user programs wouldn't see any difference. But I'm not sure if that's useful or rather a kludge ...
Adriaan van Os wrote:
As long as Peter's proposal is an option that can be turned on and off, I think everybody can be perfectly happy with it. I suggest that the option is turned off by default, except for --mac-pascal (and maybe for --delphi).
Sure.
Frank
At 12:40 AM +0200 25/7/03, Frank Heckenbach wrote:
What else?
E.g., a test program Peter sent me contained `override' which hadn't been mentioned here so far. So please (all who use Mac Pascal) check carefully if there are any more differences because they might influence the implementation.
BTW, about `override': I'm not quite sure I really understand it (also after looking in OOE). Does it do the same as BP/GPC methods without any special directive which happen to override an inherited method? What happens (in MP/OOE) if a method of the same name as an inherited methods is not declared `override', is it just an error? (Or if an `override' method does not actually override?) IOW, is there actually any behaviour (with or without this directive) that doesn't correspond to BP, or is it just different syntax?
Sorry, I didn't realize BP didn't have "override" - it's unfortunately very difficult to know all the differences between the different implementations of objects when you only know one of them - does anyone have more solid experience with both kinds (Adriaan? Gale?).
In Mac Pascal, each method name must be unique within any object (including inherited objects, recursively). A super-object may override an existing method in an (recursively) inherited object (ie, define a method with an already existing name) , if the new definition exactly matches the old definitions prototype, and the keyword "override" is specified. Otherwise, yes it is an error.
BTW, does MP have `virtual'? Otherwise we should disable this keyword in `--mac-pascal', shouldn't we?
No, and yes.
BTW, A quick idea for the object pointers: If we allow `Parent' in `type Foo = object (Parent)' to be an object pointer type, it *may* (still doubtful) be useful to make `Foo' a pointer as well. This way the syntactic difference would be limited to the root object types. This would be particularly useful if there's (by convention or requirement) only one root object type (presumable in a standard unit then), so user programs wouldn't see any difference. But I'm not sure if that's useful or rather a kludge ...
This sounds a bit dubious to me.
One possibility would be to use attributes (but I think you don't currently have type attributes, right?). If we did, presumably something like:
type Foo = object ... end; attribute( pointer );
In this case though, it would probably make sense then to behave as you describe (ie, inheriting objects would inherit the pointer attribute).
Anyway, hopefully that clears up that difference between GPC and MP. Ideally someone with more experience in both types of objects can comment further on any differences. I can clarify any issues with MP's objects, but I don't currently have any experience with GPC objects.
Enjoy, Peter.
Peter N Lewis wrote:
At 12:40 AM +0200 25/7/03, Frank Heckenbach wrote:
What else?
<snip> > BTW, about `override': I'm not quite sure I really understand it > (also after looking in OOE). Does it do the same as BP/GPC methods > without any special directive which happen to override an inherited > method? What happens (in MP/OOE) if a method of the same name as an > inherited methods is not declared `override', is it just an error? > (Or if an `override' method does not actually override?) IOW, is > there actually any behaviour (with or without this directive) that > doesn't correspond to BP, or is it just different syntax?
Sorry, I didn't realize BP didn't have "override" - it's unfortunately very difficult to know all the differences between the different implementations of objects when you only know one of them - does anyone have more solid experience with both kinds (Adriaan? Gale?).
Ironically, I have extensive experience with BP objects, but not (much) with objects in Think/MPW/CodeWarrior Pascal on the Macintosh (the reason being my thorough dislike of the object reference model). However, I have access to both GPC, BP and a Macintosh, so, if nobody has the requested information ready, I can do some research (but it would take some time).
In Mac Pascal, each method name must be unique within any object (including inherited objects, recursively). A super-object may override an existing method in an (recursively) inherited object (ie, define a method with an already existing name) , if the new definition exactly matches the old definitions prototype, and the keyword "override" is specified. Otherwise, yes it is an error.
BTW, does MP have `virtual'? Otherwise we should disable this keyword in `--mac-pascal', shouldn't we?
A quick look in the CodeWarrior Pascal Language Reference learns that CW also has the 'inherited" keyword. The GPC manual reads that "‘inherited’ is an Object Pascal and a Borland Pascal extension". However, I can't find it in the Turbo Pascal 6.0 Programmer's Guide, nor can I remember it from my BP days (which is more than a decade ago).
Regards,
Adriaan van Os
----- Original Message ----- From: "Adriaan van Os" gpc@microbizz.nl
Peter N Lewis wrote:
At 12:40 AM +0200 25/7/03, Frank Heckenbach wrote:
<snip>
Ironically, I have extensive experience with BP objects, but not (much) with objects in Think/MPW/CodeWarrior Pascal on the Macintosh (the reason being my thorough dislike of the object reference model). However, I have access to both GPC, BP and a Macintosh, so, if nobody has the requested information ready, I can do some research (but it would take some time).
In Mac Pascal, each method name must be unique within any object (including inherited objects, recursively). A super-object may override an existing method in an (recursively) inherited object (ie, define a method with an already existing name) , if the new definition exactly matches the old definitions prototype, and the keyword "override" is specified. Otherwise, yes it is an error.
BTW, does MP have `virtual'? Otherwise we should disable this keyword in `--mac-pascal', shouldn't we?
A quick look in the CodeWarrior Pascal Language Reference learns that CW also has the 'inherited" keyword. The GPC manual reads that "inherited is an Object Pascal and a Borland Pascal extension". However, I can't find it in the Turbo Pascal 6.0 Programmer's Guide, nor can I remember it from my BP days (which is more than a decade ago).
"inherited" is a reserved word in BP 7.0
Adriaan van Os wrote:
Ironically, I have extensive experience with BP objects, but not (much) with objects in Think/MPW/CodeWarrior Pascal on the Macintosh (the reason being my thorough dislike of the object reference model). However, I have access to both GPC, BP and a Macintosh, so, if nobody has the requested information ready, I can do some research (but it would take some time).
I'd rather wait than hurry things and choose a way that will lead to trouble in the future.
In Mac Pascal, each method name must be unique within any object (including inherited objects, recursively). A super-object may override an existing method in an (recursively) inherited object (ie, define a method with an already existing name) , if the new definition exactly matches the old definitions prototype, and the keyword "override" is specified. Otherwise, yes it is an error.
BTW, does MP have `virtual'? Otherwise we should disable this keyword in `--mac-pascal', shouldn't we?
A quick look in the CodeWarrior Pascal Language Reference learns that CW also has the 'inherited" keyword. The GPC manual reads that "Âinherited is an Object Pascal and a Borland Pascal extension".
BTW, I think these reference entries haven't been updated for Mac Pascal (when Peter added the support in the compiler). If someone likes to do it, just send me a diff of reference.texi (it's basically boring work to insert "traditional Mac Pascal" here and there; you can look at predef.h to make sure your entries match the compiler's idea of Mac Pascal).
However, I can't find it in the Turbo Pascal 6.0 Programmer's Guide, nor can I remember it from my BP days (which is more than a decade ago).
BP 7.0 has `inherited' (not sure about 6.0). It can be used only within method definitions of derived object types, and `inherited Foo' means `Bar.Foo' where `Bar' is the parent of the current method's object type.
Assuming it means the same in CodeWarrior Pascal, I'll keep it in `--mac-pascal'.
Frank
At 11:39 PM +0200 25/7/03, Frank Heckenbach wrote:
However, I can't find it in the Turbo Pascal 6.0 Programmer's Guide, nor can I remember it from my BP days (which is more than a decade ago).
BP 7.0 has `inherited' (not sure about 6.0). It can be used only within method definitions of derived object types, and `inherited Foo' means `Bar.Foo' where `Bar' is the parent of the current method's object type.
I assume that if Bar does not define Foo, but Bar's parent defines Foo, that is still ok.
If so, yes, that sounds the same. Peter.
Peter N Lewis wrote:
At 11:39 PM +0200 25/7/03, Frank Heckenbach wrote:
However, I can't find it in the Turbo Pascal 6.0 Programmer's Guide, nor can I remember it from my BP days (which is more than a decade ago).
BP 7.0 has `inherited' (not sure about 6.0). It can be used only within method definitions of derived object types, and `inherited Foo' means `Bar.Foo' where `Bar' is the parent of the current method's object type.
I assume that if Bar does not define Foo, but Bar's parent defines Foo, that is still ok.
Yes. In this case, Bar inherits Foo from its parent, so `Bar.Foo' will also work.
Frank
Peter N Lewis wrote:
In Mac Pascal, each method name must be unique within any object (including inherited objects, recursively). A super-object may override an existing method in an (recursively) inherited object (ie, define a method with an already existing name) , if the new definition exactly matches the old definitions prototype, and the keyword "override" is specified. Otherwise, yes it is an error.
So that's another incompatibility to BP. You may say that they don't really conflict since either way (with and without `override') would be an error in one of the dialects. But it would mean that if by default we allow the union of both dialects, `override' would mean almost nothing.
BTW, A quick idea for the object pointers: If we allow `Parent' in `type Foo = object (Parent)' to be an object pointer type, it *may* (still doubtful) be useful to make `Foo' a pointer as well. This way the syntactic difference would be limited to the root object types. This would be particularly useful if there's (by convention or requirement) only one root object type (presumable in a standard unit then), so user programs wouldn't see any difference. But I'm not sure if that's useful or rather a kludge ...
This sounds a bit dubious to me.
One possibility would be to use attributes (but I think you don't currently have type attributes, right?). If we did, presumably something like:
type Foo = object ... end; attribute( pointer );
We have type attributes, but I don't see what this would gain. You'd have to modify the type declaration, just as if you had to declare the pointer explicitly. Besides, since the attribute appears at the end of the declaration, it's not known while parsing the fields and methods. This may not be a problem now (because GPC does most of the work at the end of an object type declaration, anyway), but it would add a restriction for future changes.
Currently I tend to distinguish the object kinds strictly, i.e. specify on the declaration whether it's a BP/GPC or Mac style object. This would then influence pointers, virtual methods, `override' and anything else that may be required.
The best way to do so might be a special option. This wouldn't require new syntax, and it would usually be global (which is usually wanted), though it can be changed locally.
The disadvantage is that the default dialect then is not a superset of everything. But it would only take the flipping of an option to get it all. (It would be a separate option, of course, perhaps `--mac-objects' or so, coupled to `--mac-pascal'.) I.e., it would be possible to mix different kinds of objects in a program (though I'm not sure if it should be possible to inherit between them -- due to `override' etc., I tend not to).
Frank
On 25 Jul 2003 at 23:49, Frank Heckenbach wrote:
Peter N Lewis wrote:
In Mac Pascal, each method name must be unique within any object (including inherited objects, recursively). A super-object may override an existing method in an (recursively) inherited object (ie, define a method with an already existing name) , if the new definition exactly matches the old definitions prototype, and the keyword "override" is specified. Otherwise, yes it is an error.
So that's another incompatibility to BP. You may say that they don't really conflict since either way (with and without `override') would be an error in one of the dialects. But it would mean that if by default we allow the union of both dialects, `override' would mean almost nothing.
Override exists in Delphi as well. Contrary to the BP-style objects, you need to use "override" if you want to override a method. These excerpts are from the Delphi 7 help file:
"Overriding a method means extending or refining it, rather than replacing it. A descendant class can override any of its inherited virtual methods.
To override a method in a descendant class, add the directive override to the end of the method declaration.
Overriding a method causes a compilation error if The method does not exist in the ancestor class. The ancestor's method of that name is static. The declarations are not otherwise identical (number and type of arguments parameters differ)."
....
"If a method declaration specifies the same method identifier and parameter signature as an inherited method, but doesn't include override, the new declaration merely hides the inherited one without overriding it. Both methods exist in the descendant class, where the method name is statically bound. For example,
type T1 = class(TObject) procedure Act; virtual; end; T2 = class(T1) procedure Act; // Act is redeclared, but not overridden end; var SomeObject: T1; begin SomeObject := T2.Create; SomeObject.Act; // calls T1.Act end; " ..... "To make a method virtual or dynamic, include the virtual or dynamic directive in its declaration. Virtual and dynamic methods, unlike static methods, can be overridden in descendant classes. When an overridden method is called, the actual (runtime) type of the class or object used in the method call--not the declared type of the variable-- determines which implementation to activate.
To override a method, redeclare it with the override directive. An override declaration must match the ancestor declaration in the order and type of its parameters and in its result type (if any).
In the following example, the Draw method declared in TFigure is overridden in two descendant classes.
type TFigure = class procedure Draw; virtual; end; TRectangle = class(TFigure) procedure Draw; override; end; TEllipse = class(TFigure) procedure Draw; override; end;
Given these declarations, the following code illustrates the effect of calling a virtual method through a variable whose actual type varies at runtime.
var Figure: TFigure; begin Figure := TRectangle.Create; Figure.Draw; // calls TRectangle.Draw Figure.Destroy; Figure := TEllipse.Create; Figure.Draw; // calls TEllipse.Draw Figure.Destroy; end; "
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
-
Adriaan van Os -
Frank Heckenbach -
Gale Paeper -
Jose Perez -
Peter N Lewis -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)