Le 08/03/2012 12:55, Steven Schveighoffer a écrit :
On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana <a...@esperanto.org.ar>
wrote:
The problem is not mistaking it with something else. The problem is
when you want to write it. In Ruby my mind works like this:
Mind: "How would I get a span for 5 seconds?"
Mind: "Let's try 5.seconds"
Mind: "Wow, it works!"
I'm trying to remember cases when I just wrote what my mind thought it
was correct and I was *so* surprised it worked out of the box in Ruby.
Like writing array.last, and get it to work, instead of
array[array.length - 1]. But in D, from the docs
(http://dlang.org/arrays.html )
bar[$-1] // retrieves last element of the array
I read: bar dollar minus one wait what??
array.back;
http://dlang.org/phobos/std_array.html#back
This is the issue with "intuition". It's easy to say, "hey I guessed
right in Ruby! Ruby must be more intuitive!". But if you were someone
who knew the range interfaces, wouldn't you try array.back in Ruby and
say "well, obviously D is more intuitive, it knew what I wanted without
even looking up the docs!"
You are never going to come up with something that's *perfectly*
intuitive for everyone in every situation.
Now, in D I try:
5.seconds
and it doesn't work. I have to write this very unintuitive:
dur!"minutes"(5)
Was it really necessary to implement it that way?
No, nothing is ever necessary to implement a certain way. But there are
practical concerns. For example, assuming UFCS worked in D, you *could*
possibly do 5.seconds. However, this means you need a module-level
function:
Duration seconds(long n) {...}
But the way D's overload resolution works, this precludes having
5.seconds work, and also having a member named 'seconds' in your
class/struct.
The nice thing about dur!"seconds" is that only one module-level symbol
is introduced (dur), and it's unlikely to conflict with local symbols
It may not be as intuitive, but it's certainly readable, and not too
verbose to type.
-Steve
the shorter the symbol, the higher the probability of collision. This is
math. Definitively an argument in favor of not abbreviating.
