Arbitrary abbreviations in phobos considered ridiculous

deadalnix deadalnix at gmail.com
Thu Mar 8 14:56:58 PST 2012


Le 08/03/2012 12:55, Steven Schveighoffer a écrit :
> On Wed, 07 Mar 2012 21:14:34 -0500, Ary Manzana <ary at 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.


More information about the Digitalmars-d mailing list