On 04/20/2011 01:09 AM, 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:
auto connections = taskPool.workerLocalStorage(new MysqlConnection());
Anyone who is not familiar with std.parallelism and D's lazy parameter feature
is going to be very surprised to find out what this code really does. This
might be OK for us, experienced D users, but think about the poor bloke who
will someday, somewhere try to debug a D program written by someone else, and
tear his hair out trying to figure out why an expression passed as an argument
to some function isn't being evaluated before/during the function call. (The
solution I would suggest is simply having to specify the "lazy" keyword before
the expression of each lazy parameter, same as C#'s "ref". This will require
updating all usage of "enforce" among other changes.)
[...current vote about std.parallel...]
For the moment, I would suggest
changing all lazy parameters which are evaluated in different contexts (outside
of the said function) into delegates, and replacing their usage with delegate
literals.
Sounds very good to me.
Denis
--
_________________
vita es estrany
spir.wikidot.com
