From: dblack@...
Date: 2006-07-21T22:28:42+09:00
Subject: Re: opacity of magic enumerator (was: Re: Using .each with constructors)

Hi --

On Fri, 21 Jul 2006, Martin DeMello wrote:

>> Maybe part of the problem is that it suggests an equivalence between:
>>
>>    [0,1,2].map {}
>> 
>> and
>>
>>    3.times.map {}
>> 
>> which makes it seem like 3.times is return an array.  Or something.  I
>> don't even know exactly; it just reads very badly to me.
>
> There I agree with you - it's handy, but unaesthetic for 3.times to
> yield 0, 1, 2 rather than nil, nil, nil

Yes: I think you've pinpointed an underlying problem with "times".
It's really "times_with_index", in a sense, but it's just called
"times".

That's probably why the upto version is much clearer to me (see my
last post, in reply to Robert).

>> I'm also still troubled by the rather wide net cast by magic
>> enumerators.  I don't think anyone came up with an answer to my
>> earlier question: When would you ever need this:
>>
>>    some_enumerable.map.other_method
>> 
>> ?  If the answer is "never", then I don't think map should return an
>> enumerator.
>
> That is indeed a good point, and 'consistency' is the only thing I can
> offer in its favour. It might be a decent optimisation for 'map' to
> return self rather than an enumerator.

There's another kind of consistency, though: consistent attention to
finding what's exactly right for every syntactic and semantic
component of Ruby, one at a time, whether it's just like others with
which it has something in common or not :-)  I really think it would
be worth hand-crafting these return values based on what each method
actually does.


David

-- 
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
http://www.manning.com/black     => RUBY FOR RAILS (reviewed on
                                     Slashdot, 7/12/2006!)
http://dablog.rubypal.com        => D[avid ]A[. ]B[lack's][ Web]log
dblack@wobblini.net              => me