views:

232

answers:

3

I'm trying to create a little Ruby hack to make something like the reverse of the Symbol#to_proc hack. Whereas the Symbol#to_proc hack makes this possible:

some_array.each(&:some_method)

is the same as

some_array.each { |obj| obj.some_method }

I want to make this possible:

some_array.each(&[:some_method])

would be the same as

some_array.each { |obj| some_method(obj) }

The problem is that unless some_method is a kernel method, what it would really mean is:

some_array.each { |obj| self.some_method(obj) }

When an block is passed explicitly, it's created within the binding where this line is written, so self correctly accesses the current object and everything works fine. However if the block is created in the Array's to_proc method, self is within the Array binding (and refers to the array itself). Perhaps it's not possible to do what I'm trying to do, but I'd love some ideas from the community.

Here's my hack so far. This works as long as the method is a kernel method, and is available within Array:

class Array
  def to_proc
    lambda {|i| send(self.first, i)}
  end
end

With this hack, this line works, and puts the three symbols:

[:foo, :bar, :bas].each(&[:puts])

It's useful to me already, because often I'm finding myself wanting to inspect an array of ActiveRecord objects within the console and it saves me from typing { |i| puts i}. But it would be even more useful to be able to use it within objects so that some method within the object gets called with every item in the array passed as a parameter.

So any idea how to make the binding issue work?

Please don't both responding with "you don't want to do this because it'll make things run slower" or "you're not saving so many characters typing, but it makes the code less readable" -- I know these things already. :) This is more of a feeding my curiosity kind of hack. Just wondering if it's possible.

+1  A: 

Here is another way to do it without using the method() method :). It uses a block to capture the binding and then invokes the relevant method on the self of the binding.

class Object
    def apply &block
        b = eval('self', block.binding)
        lambda { |param| b.send block.call, param }
    end
end


# use like this:
[1, 2, 3, 4].each &apply { :puts }

output: 1
        2
        3
        4
banister
Ooh, that's friggin cool. This solution is closer to what I was initially intending.
Allan Grant
+4  A: 

You are looking for the method called method :)

class Example
  def some(arg)
    p arg.size # just as a demo
  end
end

obj = Example.new
%w{the quick brown fox jumps over the lazy dog}.each(&obj.method(:some))

yields

3
5
5
3
5
4
3
4
3
Adrian
+1 simple and sweet answer :)
banister
That's.. exactly what I was looking for! :) Thanks.
Allan Grant
Glad I could help.
Adrian
+1  A: 

Although Adrian has the right idea there with using the method method, you can simplify this a step further:

# Works on any generic method
%w{the quick brown fox jumps over the lazy dog}.each(&method(:foo))

def foo(arg)
  p arg.size
end

# Works on user-defined methods, too
%w{the quick brown fox jumps over the lazy dog}.each(&method(:puts))

Instead of making some awkward semantics with the introduction of Array#to_proc, why not just write your own Enumerable methods that make your life easier instead? Perhaps something like this:

module Enumerable
  def pass_each(method_name)
    each(&method(method_name.to_sym))
  end
end

%w{the quick brown fox jumps over the lazy dog}.pass_each(:puts)
tadman
That's a really good idea with making a new Enumerable method, but I'd like to be able to use this trick with all the various Enumerable methods, like each, map, reject, etc. Thanks!
Allan Grant
in your `pass_each` example won't the `method()` method be executed in the wrong context (the context of the receiver) and so not have access to the right methods?
banister
The method has to be declared within the main context or it won't be very useful, yes. Otherwise it's quite a mess to get that method call to work on the active context.
tadman
@tadman, but that means the behaviour of your `pass_each` approach and the first approach you mentioned (Adrian's one) are completely different.
banister