▲ | vinceguidry 15 hours ago | |||||||
You shouldn't have much difficulty, Ruby converts blocks to Procs whenever it needs an actual object. Their semantics are intentionally kept the same. This is unlike lambdas, whose semantics are closer to methods. Pass the wrong number of of arguments to a Proc or block, it will pass nil for missing args and omit extras. Pass the wrong number of arguments for a method or lambda and you get an ArgumentError. Use the return keyword in a lambda, it returns from the lambda, just like if you call return in a method. In a block or Proc, it returns from the calling method. So I would feel comfortable leaning on them for refactoring as it's as Ruby intended. Just use lambdas when you want to turn methods into objects and Procs when you want to objectify blocks. You should get ahold of a copy of Metaprogramming Ruby 2 if you find yourself refactoring a lot of Ruby. It's out of print, but ebooks are available. | ||||||||
▲ | vidarh 14 hours ago | parent [-] | |||||||
Just to clarify here: Both lambdas and procs are Proc objects. Blocks gets turned into Proc objects when you take their value. So just be clear about whether you're talking about a proc or a Proc... > In a block or Proc, it returns from the calling method No, in block or a Proc it returns from the scope where it was defined. Usually this is the same, and so it doesn't usually matter much, but if you pass a proc or a block down to another method, then a return within the block will still return from the method where it was defined. This can occasionally be useful, as you can use it to pass in a predicate to a method that can control if/when you want to return, irrespective of how deeply nested. | ||||||||
|