On 20/04/2011 00:09, Vladimir Panteleev wrote:
To elaborate, I mean allowing code which appears to behave surprisingly
different from the at-a-glance interpretation, unless the programmer
knows the function's signature. I've noticed a worrying adoption in D of
this "antipattern", which, frankly, I believe doesn't belong in a
well-designed programming language. One classic example of this is
passing arguments by reference, something D inherited from C++. For
example:
int x, y;
// ...
someObject.updateCoords(x, y);
What can you say about this code? The unobvious and surprising
interpretation of it is that updateCoords will change the values of x
and y. C# solved this problem neatly by requiring to specify the "ref"
keyword before the function arguments:
someObject.updateCoords(ref x, ref y); // much clearer
This problem carries over to lazy parameters, as well. I'll quote a line
of code from a recent post by David Simcha:
This problem is also very similar to the named arguments problem
(figuring out which argument corresponds to which parameter when there
are many parameters and they all have the same type).
My response is the same as the named arguments issue: I think it is
preferable (if not preferable, then at least sufficiently good) to use
an IDE to look up the full function signature, than to make language
additions to make the call clearer by just looking at the source text.
Your post actually adds a bit more value to my approach, because it
shows my approach is the same no matter what you want to figure out
about the arguments (if they are ref, lazy, to which named parameter the
argument corresponds, etc.), and it also brings up the full DDoc with
the full information describing what the function does.
Conversely, your approach does not scale in a sense, because you need to
keep adding stuff for each new thing you want to know about the
parameter (ref, lazy, named argument, etc.). Should we add variadic
parameters to the mix as well? What else? Taking this approach to the
extreme, we might as well replicate all the information in the function
signature in the function call...
--
Bruno Medeiros - Software Engineer
