Hi Folks!
Frank Heckenbach wrote:
Markus Gerwinski wrote:
This results in a 'Header does not match previous definition' for function Bar.
Yes, according to the standard (*), the result variable must be present in the original declaration as well. GPC didn't check this before, but does now.
(*) This is only stated in the Object-Oriented Extensions, 6.7 (d):
: [...] and if one function definition contains a result variable : specification, then the other also has a result variable : specification of the same spelling.
What's the point in declaring a local result variable in the unit interface?!?
I mean, the code
Function bar = result: integer; begin (* bar *) ... end (* bar *);
is, in fact, nothing but an abbreviated way to write:
Function bar: integer; var result: integer; begin (* bar *) ... bar:= result; end (* bar *);
So `result` is actually a local variable, and no module using the unit will ever be able to access it. Why put it into the interface?
I'd definitely feel more comfortable if we could skip the standard here and permit the other syntax again...
Regards,
Markus __________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201
Markus Gerwinski wrote:
... snip ...
What's the point in declaring a local result variable in the unit interface?!? I mean, the code
Function bar = result: integer; begin (* bar *) ... end (* bar *);
is, in fact, nothing but an abbreviated way to write:
Function bar: integer; var result: integer; begin (* bar *) ... bar:= result; end (* bar *);
So `result` is actually a local variable, and no module using the unit will ever be able to access it. Why put it into the interface?
I'd definitely feel more comfortable if we could skip the standard here and permit the other syntax again...
My own attitude is that the use of result is pointless in the first place. It gains nothing that I can see over the standard method "bar := ...". In fact I like to code many things as:
FUNCTION foo : T
VAR anotherTvalue : T
BEGIN foo := someTvalue; (* default *) .... IF whatever THEN foo := anotherTvalue; .... END;
Please show me something that the traditional method can't do.
Markus Gerwinski wrote:
... snip ...
What's the point in declaring a local result variable in the unit interface?!? I mean, the code
Function bar = result: integer; begin (* bar *) ... end (* bar *);
is, in fact, nothing but an abbreviated way to write:
Function bar: integer; var result: integer; begin (* bar *) ... bar:= result; end (* bar *);
So `result` is actually a local variable, and no module using the unit will ever be able to access it. Why put it into the interface?
I'd definitely feel more comfortable if we could skip the standard here and permit the other syntax again...
My own attitude is that the use of result is pointless in the first place. It gains nothing that I can see over the standard method "bar := ...". In fact I like to code many things as:
FUNCTION foo : T
VAR anotherTvalue : T
BEGIN foo := someTvalue; (* default *) .... IF whatever THEN foo := anotherTvalue; .... END;
Please show me something that the traditional method can't do.
I'd definitely feel more comfortable if we could skip the standard here and permit the other syntax again...
My own attitude is that the use of result is pointless in the first place. It gains nothing that I can see over the standard method "bar := ...". In fact I like to code many things as:
It's not really a question of what advantages the facility gives, since no one is arguing for the facilities removal. The question is the wisdom of requiring the variable to be specified in the in the interface section. It seems this is an implementation only detail, which would be better left to only the implementation. I agree with Markus, if a user goes and rewrites the function in a different style using the result variable, they should not need to change the interface to do so.
Enjoy, Peter.
-
CBFalconer -
Markus Gerwinski -
Peter N Lewis