Am I the only person who doesn't really like "returning"?

a) it's no fewer lines & no fewer tokens b) rather than looking at the bottom of the function for the return value, you now have to scan back to the top

I think this suggestion of using 'tap' in this way is awful. Use 'tap' in the way that the name suggests: to tap into the middle of a string of code, generally temporarily, generally for debugging.

You're not the only person. I'm the author of this post and I'm not even sure I like returning() :)

I'm mostly pointing out the similarity for the sake of discussion, and as it seems to be playing out in the comments, using this approach is a bad idea.

Maybe that'll serve as a lesson to those who are tempted to think as I did.

At the risk of starting a language riot: both of these techniques seem awfully clunky. Python's dictionary comprehension syntax solves the same problem in a single expression.

Whether it's a problem worth solving in syntax is left as an exercise for the reader. I mean seriously: create and fill a hash. Is that really something we want to be worried about?

I am not up on my python, but I'm definitely interested in knowing more.

I looked at this: http://www.python.org/dev/peps/pep-0274/

List comprehensions are great, but they're typically used for iteration/map-like functionality, right?

For this, we could use with_object in Ruby (as mentioned in this article).

The question was more about if you have an iteration combined w. other transformations that are not iterative.

Is that something that could still be solved with dict. comprehensions? If so, I'd definitely like to see it for inspiration.

But it's definitely a valid question as to whether we should even bother to worry. The purpose of this series of articles is to expose ideas around Ruby 1.9 features, to see whether they sound promising or not. This one, maybe not so promising :)

The example given -- evaluating a new hash mapping the keys x, y, and z to random numbers in the range [0:100) -- is expressible in python3 as:

  {(x, random.randrange(100)) for x in ["x", "y", "z"]}

My point wasn't that "tap" is identical in functionality, it was actually the opposite: for the use cases here, both "tap" and "returning" are inferior to the python syntax.

That said, I continue to assert that this is a dumb example and you should just initialize the empty hash like your parents did.

  "{(x, random.randrange(100)) for x in ["x", "y", "z"]}"

FWIW, it's possible to do it as a one liner in Ruby 1.9 without tap:

  Hash[[:x, :y, :z].map { |l| [l, rand(100)]}]

There may be other ways to do it (like inject, as mentioned in the post). That said, tap is probably more confusing and not necessarily shorter than:

  result = {}
  [:x, :y, :z].map { |l| result[l] = rand(100)}
  result

You clearly didn't bother to read beyond the 'dumb' example.

And the predicted language riot has begun.

Edit: I should probably add some content before I get (rightfully) downvoted into oblivion:

The latter example is a pure noop. Instead of computing some values using local variables and returning a hash composed of them as the last expression in the block, it does a dance with tap (extra syntax!) and scopes all the variables to the tapped object (extra syntax) instead of the default lexical scope.

All I can see is that tap adds complexity. At least the first example simplified things (albeit not as well as alternative syntaxes from other languages).

That's not the case at all. I was asking how you do this with dict comprehensions:

http://pastie.org/573042

I'm pretty sure the answer is "you don't", unless it requires setting a variable explicitly and returning it (same as in Ruby).

Since your last comment didn't address that at all, I literally meant you didn't read the whole post, not that I had some secret magic up my sleeve.

Yep, and that's what most of the comments on the blog are saying, and I am coming around to agree with them. To put this in context, I am discussing new Ruby 1.9 language features in Ruby 1.9, and how tap can be used to do away with a 3rd party Rails feature (returning).

Whether returning is useful in the first case is a whole other can of worms, and while I still sort of like the aesthetics of it, the technical points people are making in the comments are totally sound, and I might avoid it for that reason.

Also have a look at Perl6 gather/take for another way: http://perlcabal.org/syn/S04.html#The_gather_statement_prefi...

Its also been ported back to Perl5: http://search.cpan.org/dist/Perl6-Gather/Gather.pm