From: Trans <transfire@...>
Date: 2006-11-16T11:35:08+09:00
Subject: Re: #returning and #tap


Eric Hodel wrote:

> Most of the time it adds code.  Look at the two examples on the blog
> post.  In the returning case I add "returning do || end" in the
> simple case I have an extra "=".

> The example shows in the blog post shows returning saving exactly 0
> lines of code.  It claims that in some cases it saves lines, but
> doesn't give any examples, so it is probably a very rare statement.

> If it commonly saved lines then I'd expect the blog post would have
> used such an example.  I doubt that it commonly saves lines (the blog
> post implies it usually does nothing to the line count).

> In most every other place in ruby the last line of a code grouping
> construct is the return value.  This is the way I've been reading my
> Ruby for years.  With #returning the return value is buried in the
> middle of the line between "returning" and "do".

> That's extra state I have to keep in my brain to keep the code straight.
>
> Traditional code doesn't require me to hold extra state in my head
> because its linear.  Linear is simpler and simpler is more readable.

> This statement is orthogonal to the use of #returning.  You may throw
> in extra returns anywhere you like regardless of the #returning block.

> Its simpler to just not have it at all.  #returning gives no great
> benefit and has many downsides.

> #returning isn't going to add any structure since it doesn't really
> do anything.  You're really just replacing 'var' with 'end' and
> adding a bunch of whitespace.

Well, it does add structure, otherwise there would be not be any point
whatsoever. You may or may not like that structure and certainly you
make some fair points. But if I can ask you a question: do you use this

  f = File.open('foofile')
  ...do stuff with f...
  f.close

Or do you use

  File.open('foofile') do |f|
    ...do stuff with f...
  end

B/c all of your above arguments appear equally applicable here. The
block form of File.open provides a similar kind of structure. And while
you might say that the block form of File.open ensures the file is
closed, which gives it it's value, I say there in lies a complementary
point. A properly implemented #returning would ensure that only the
specified object is returned, and nothing else --so internal returns
would not work, because that is the structure it provides.

> > Besides that the 'tap' functionality can be very helpful in it's own
> > right.

> So what? I didn't mention #tap in my email.

B/c even if we were to agree that #returning has little value in the
context presented, both it and #tap have have the same exact
definition. Hence it has use in other contexts as well. Since
#returning has greater semantic recognition, why have #tap at all when
#returning would do as well?

BTW, is seems a bit arrogant to presume yourself the hallmark of
relevancy. I brought it up b/c I saw it as relevant. I'm sorry I did
not elaborate on the relationship. I mistakenly assumed it was plain.

T.