On 29 Apr 2003 at 15:22, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
Actually, there is a documented way of accessing the dynamic method index. I found it in the Delphi help file, and you won't like it - the access method is via asm. In any case, below is the documentation - and you can do with it (or not) as you deem fit. In the example given, "message MYMESSAGE" is the same thing as the BP "virtual methodindex".
Well, GPC's `asm' in incompatible to BP's -- that's known, and not likely to change. (And even if it would, such an implementation would be unnecessarily(*) nonportable by the use of asm.)
Agreed. There is no justification for using asm for this type of access (i.e., assuming it can be done in Pascal).
(*) In some low-level cases, such as accessing I/O hardware ports, the use of assembler code is unavoidable (though it is debatable whether it should be inlined in Pascal, or linked separately, but that's not the point here), but here we have a feature that can be described in high-level terms and in principle be implemented in high-level ways (`case' etc. ...), so the use of `asm' is an unnecessary restriction.
Agreed.
So, I won't do anything with it now. I still think an (automatically generated) `case' statement can work.
Probably - except that, in your suggestion, the utility to do this will be extraneous to GPC itself. The use of an external utility is IMHO an extra complication and overhead.
procedure DynamicMethod; dynamic;This syntax seems to be new in Delphi (BP doesn't allow it). Should I just treat is as equivalent to `virtual'? (Since there's no index there, I suppose the dispatch issues don't apply here, and this time it's really equivalent, apart from memory and speed issues.)
Yes, it is new in Delphi - and it is only valid where you are defining a "class", rather than an "object". For example, this is accepted by Delphi:
type bar = class procedure foo; dynamic; end;
But this is not accepted: type bar = object procedure foo; dynamic; end;
Since both BP and Delphi reject it, there is a case for GPC rejecting it too. On the other hand, perhaps this is an unnecessary restriction and so GPC should accept it. I have no strong view either way.
It gets more interesting, with regard to type-safeness. Given this; type bar = class procedure foo1; message 1; procedure foo2; virtual 2; procedure foo3 (var msg : tmessage); message 3; procedure foo4 (var msg : integer); message 4; end;
Both "foo1" and "foo4" are rejected with "Error: Invalid message parameter list".
"foo2" is rejected with "Error: ';' expected but number found" (but it is accepted where "bar" is defined as "object" rather than "class").
"foo3" is accepted. There you have type unsafeness dealt with. As in BP's OWL, you *are* required to have the "var foo : tmessage" parameter. But here you get a compiler error, whereas BP would accept it without the parameter, and then the program will crash when the method is called. This might mean that the dispatcher for "message index_number" (equivalent to BP's "virtual index_number") is now implemented in the compiler and not in the OOP library - but who knows?
BTW: all this is of no relevance until when/if the "class" construct is fully supported. Indeed, whether one should copy all this behaviour is debateable.
[...]
- "Virtual versus dynamic
Virtual and dynamic methods are semantically equivalent.
Ha! :-)
Yes ...
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/