
Should I Tap that Hash?  (Ruby 1.9 Style) - sant0sk1
http://blog.rubybestpractices.com/posts/gregory/011-tap-that-hash.html
======
kscaldef
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.

~~~
sandal
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.

------
ajross
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?

~~~
sandal
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 :)

~~~
ajross
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.

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

~~~
ajross
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).

~~~
sandal
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.

