From: furtive.clown@...
Date: 2007-11-13T18:10:02+09:00
Subject: Re: Yielding an object and caring about the result: the cousin of Object#tap

On Nov 13, 3:12 am, Robert Klemme <shortcut...@googlemail.com> wrote:
>
> IMHO introducing temporary variables with proper names can go a long
> way to make this piece much more readable. (The same holds true for
> method names.)

OK, point taken about the proper name.  Nonetheless I am surprised
this is not a unanimous slam dunk.  The contenders are:

   all_inputs = source_files +
      transform1( stems.map { |f| f + "." + guess_extension(f) } )
   all_files = transform2( all_inputs ).map {|f| File.join dir, f}

verses

   all_files = stems.map { |f|
      f + "." + guess_extension(f)
   }.as { |all_inputs|
      transform2(source_files + transform1(all_inputs))
   }.map { |f|
      File.join dir, f
   }

Since I have been accustomed to using #as for years, the latter looks
canonical and the former looks quirky and too clever.  Three things
come to mind:

(1) Parentheses adjacent to brackets are an eyesore.

(2) The latter is step-by-step linear and easier to follow: one
transformation, then another, then another.  Simple.  The former takes
much more studying in order to understand, relatively speaking.  That
is, my strategy for understanding it is to work from the inmost
expression outward.  But in the latter case, I work linearly from
start to finish.

(3) What is the purpose of all_inputs?  Is it there as an
intermediate, or do you want to use it for something else?  Should I
keep a mental note of it, or should I discard it in my mind?  In the
former case, I am left wondering all of this.  In the latter case the
answer is clear: it's a temporary for building all_files, to be
forgotten as soon as possible.

I am a lone rubyist who went off the grid several years ago after
contributing a project on rubyforge, so perhaps *my* style is the
quirky one.  Still, in my mind the latter is sheer elegance compared
to the former.  I actually find it interesting that someone could
possibly disagree.  Do (1)-(3) make any sense, then?

Regards,
-FC