On 2010/01/31 10:30 AM, Daniël Mantione wrote:
This behaviour is intentional to allow you to read instead of just
write the function result. The incompatibility just affects recursive
procedures without parameters, which seldomly occurs, because normally
the parameters determine the behaviour of the function, and a
recursive function without parameters would prevent you writing a
mechanism that makes the recursive function terminate.
Only if the behaviour of the recursive function is controller by
global variables, then you can actually write a recursive function
without parameters. Because this is so seldom, and the desire to read
from the function result is extremely common, there is a strong case
for this behaviour.
OK, thanks. Also to Cobines for pointing out $mode delphi works as (I)
expected. I'm deliberately writing new units to compile with $mode
objfpc so I still have lots to learn. I do think a compiler hint would
be nice, either at the method declaration ("Hint: Overloaded function
without parameters may conflict with function result value.") or when
using the function name as the result in code ("Hint: Ambiguous use of
function name; use () if you wanted to call the overloaded function
instead"). Or perhaps I must get used to using() for functions without
parameters, and even better: give me another $mode where (like C++)
MethodName; is equivalent to @MethodName, so I'd be forced to use (). :-)
Indeed Borland did invent "result" as a method to read from the
function result, so FPC had to support that too.
I must say I prefer Result. It reads much easier, so I'd say it is more
to the spirit of Pascal than to have to use () to disambiguate things.
(So Borland /did/ actually invent some useful stuff....)
Being able to read the result is +1 Pascal, -1 C. If only I can have
"var I, J: Integer;" anywhere between a begin and end and (inline)
method implementations inside class definitions... sigh :-)
And to regain my productivity: to figure out how to debug with Lazarus
the way I'm used to in Delphi...
Regards,
Paul.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
