Re: Yielding an object and caring about the result: the cousin of Object#tap

Let's compare them again.  I changed some variable names which will
hopefully remove that red herring from the conversation.  I also made
the styles more consistent for better comparison.  (I was going to
show both my style and your one-liner style, but it was too
distracting.)

Temporaries in the scope of the target all_files:

  data_files = stems.map { |stem|
     "#{ stem }.#{ guess_extension stem }"
  }
  basenames =
     add_suffixes(source_files + add_prefixes(data_files))
  all_files = basenames.map { |basename|
     File.join dir, basename
  }

Temporaries inside block chains:

   all_files = stems.map { |stem|
      "#{ stem }.#{ guess_extension stem }"
   }.as { |data_files|
      add_suffixes(source_files + add_prefixes(data_files))
   }.map { |basename|
      File.join dir, basename
   }

(BTW 'suffix' here means the chars right before the dot; after the dot
I call the extension.)

I almost editorialized the headings as "Temporaries floating around
randomly, obscuring the target all_files," and "Temporaries tucked
away safely inside block chains, leaving the lone target all_files for
all of us to see."

> > I have not had such problems with exception traces.  Emacs parses the
> > trace, so I've never had a problem tracking exceptions down.
>
> well although that may sound heretical to me (vim user ;-)) i was
> thinking more along the lines of debugging production code where you
> typically just have some logs or, as i'm currently doing, debugging
> stacktraces hand written and walked out of a classified facility!
> (seriously)

I use emacs with vi bindings; you might say I'm the product of a mixed
marriage.  I get Hanukkah presents *and* Christmas presents,
metaphorically speaking.

The stacktrace argument holds no water with me.  Is there a ruby bug
in the line-number reporting?  I don't see the issue here.

> for the record, i would use #as just as i use #eval and co.  as far as
> clarity goes, maybe you come from a functional background, but i've
> never found stringing lambdas together as very clear.

This is part of my motivation here.  The block-chains above are
beautiful to me.  Concise, clear, and everything else.

Several years ago I experimented with writing ruby in a functional
style where it seemed appropriate.  I loved the results.  There is a
lot to say here.  In short, I became a better ruby programmer (which I
didn't think was possible!).  By functional style I mean functional
style in the small, such as inside the definition of a method.
Thinking in terms of transformations, removing or reducing side-
effects --- well, I won't get into it now.

> i also typically prefer
>
>   response = http.response
>   response.foo
>   response.bar
>
> to
>
>   http.response.foo
>   http.response.bar
>

That's not an example of functional style.  That's using a local
variable verses not doing so.  It has nothing to do with functional
style.

Part of your response attempts to conflate #as with #eval,
#instance_eval, #returning, singleton objects, and perhaps also the
kitchen sink.  However we are talking about #as.  I do not accept this
argument-by-association.  If you wish to make an argument against #as,
you are obligated to address #as directly.

> i guess in the end i'm being more critical of the particular example
> you gave rather than #as on the whole - but #as just seems to have a
> little code smell too it since it loses much of it's power inside a
> small method where local vars get popped anyhow

On the contrary, every local variable removed from the target
variable's scope is a win.  Even if it's one variable, that's a win.
That's one less distraction to the purpose of the code.  Or two, such
as in the example above.

If a programmer is making huge, complex method definitions and refuses
to split them up, then there's nothing we can do about it.  Your
argument seems to be, "Well, with #as, those huge definitions will
become more manageable, and therefore #as will encourage the
programmer not to split them up."  It is difficult to explain the
ridiculousness in that line of thinking.  In the meantime, good
programmers will correctly use smaller definitions while benefiting
from #as (or, at least I benefit from it).

>
>   def foobar
>     tmp = self
>     someting_with tmp
>   end
>
> vs
>
>   def foobar
>     self.as{|tmp| something_with tmp}
>   end

Straw man.  Nobody in their right mind would do that.  That's not an
argument against #as.

I have yet to see a legitimate argument against #as here, save for the
clutter argument which also applies to #tap etc as well.  I can
appreciate that to some degree, yet in many years I have not seen one
case of an actual problem arising from it.

My point is inherently difficult to make because it requires an
appreciation of method chaining and block-chaining.  In the larger
context, an appreciation of functional style is also involved.  So,
try it out for six months: if you still don't like it after that, then
you can return it for a full refund.