Prof A Olowofoyeku (The African Chief) wrote:
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.
Which should be hidden from the user. For now, a Makefile is one way to do it. In the future, we can think about integrating it into the gp utility (which might be a good place for all such kinds of things).
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.
I don't know. When we implement `class' sometime, we'll see how similar or distinct it will be to `object' and whether it simplifies or complicates things to allow both's directives for both.
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.
So at least this problem is dealt with (though apparently not the dispatcher, from Pascal code). However, this ties a syntax construct to one particular object class -- can't say that I particularly like this ...
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?
I don't. But if it's in the compiler, it must be somehow available to the library that uses it (and this doesn't seem to be the case) ...
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.
Yes, I think, we can postpone this discussion until `class' is being implemented ...
Frank