From: mrilu <mrilu@...>
Date: 2000-04-21T18:43:55+02:00
Subject: [ruby-talk:02558] Re: Default naming for iterator parameters

On Fri, 21 Apr 2000, Yukihiro Matsumoto wrote:

> In message "[ruby-talk:02535] Default naming for iterator parameters"
>     on 00/04/20, mrilu <mrilu@ale.cx> writes:
> 
> |{'foo' => 'bar', 'dog' => 'bert'}.each_pair {
> |  |key, value|
> |  print key, ": ", value, "\n"
> |}
> |I thought being able to set default iterator parameter naming *might* 
> |be good idea.

Now, there seems to be basically two arguments against default variable
names.

The first, 

Matz:
> Hmm, I'm too lazy to learn magic variable names for each methods. 

Quinn, Andy:

>The lazy part of my brain (which is also sizable) does not like the idea.  It
>objects to having to learn the "magic" words for each iterator I use.  This

I think these are basically the same thing and I can't agree. The more I
think about this the more convinced I am that as a user of an iterator
short hand form could make things easier (or lazier :). And if needed you 
can use the long form anyway.

My point is based mostly on the fact in the beginning I have to skim 
through the docs all the time reading foo.each{ |index| } or something. 
After a while  I begin to remember the iterator signatures and I'm able
to write code without lookups. At that point I recall for this iterator 
there's only one variable which role is index. If I want to rename it, 
it goes like now but if the role is a good name, which I think is the 
case usually (that is with small iterators) why bother to write it again.

So, there's the second point:

>reading other people's code:  "where'd *that* variable come from?  hmm, not up
>here, not over here, oh it maybe it's one of those magic parameters, where's
>the documentation for this iterator?  well, it's coming from the object `foo',
>so what class is `foo'?  *page page* aha, looks like it's a Bar, or maybe a
>subclass.  well, there is no doc for Bar#iterator, but aha, the Baz mix-in
>does have iterator!  ok, now where was I?"

This could be very true. We might lose some readibility. I don't have so much
experience of the world of Ruby iterators to be able to judge whether 
one can associate iterators variables at once or it will cause confusion.

I bet on confusion on longer iterators, but then I could ask was it good idea
in the first place to write such code? Not to name the non-obvious, or hide the
code flow under massive pile of code? Here I need some help
from veteranes? Do you write

foo.bar {
  zaq = prepare_for_big_code(foo)
  too_big_block_to_write_directly(zaq, bar)
}

Quinn:
>the same time.  I gave up on perl because of too much thrashing between code
>and the man pages.

I agree. And Perl coders necessary man page usage hit the spot too. It's 
easy to generate unnecessary details. But somehow it's easier for me 
to understand 

  array.each{ print element } 

than 

  array.each{ |element| print element }

The latter case is not trashing on my brain, but surely paging for 
because of "unnecessary" variable declaration :).

One small point.

> What would you propose if the there were already local variables
> that had the same name as the default ones?

I can't see this to be problem at all (like somebody else agreed too), 
since you're always able to (re)name iterator variables. 

And one last and small point.

{'foo' => 'bar', 'dog' => 'bert'}.each_pair {
#  |key, value|
  print key, ": ", value, "\n"
}

The version without |declaration| is better prepared for change of
parameter passing. If we suddenly want to change the call to |value,key|
the above code needs no change :).