4 ms·

Should I Tap that Hash? (Ruby 1.9 Style)

19 points by sant0sk1 17y ago

kscaldef 17y ago
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 17y ago
  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 17y ago
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 17y ago
  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/ 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 :)
  - draegtun 17y ago
    Also have a look at Perl6 gather/take for another way: http://perlcabal.org/syn/S04.html#The_gather_statement_prefix 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 http://search.cpan.org/dist/Perl6-Gather/Gather.pm
  - ajross 17y ago
    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 17y ago
      You clearly didn't bother to read beyond the 'dumb' example.
      - ajross 17y ago
        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 17y ago
        That's not the case at all. I was asking how you do this with dict comprehensions: http://pastie.org/573042 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.

19 points by sant0sk1 17y ago

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 17y ago
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 17y ago

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 17y ago
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/ 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 :)
- draegtun 17y ago
  Also have a look at Perl6 gather/take for another way: http://perlcabal.org/syn/S04.html#The_gather_statement_prefix 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 http://search.cpan.org/dist/Perl6-Gather/Gather.pm
- ajross 17y ago
  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 17y ago
    You clearly didn't bother to read beyond the 'dumb' example.
    - ajross 17y ago
      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 17y ago
        That's not the case at all. I was asking how you do this with dict comprehensions: http://pastie.org/573042 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.