Method calls often look like local variables; that's not a problem in and of itself. Also, once you start renaming methods to free up variable names, it's hard to know where to stop (Array#length? String#upcase? Kernel#clone?). I don't think there's anything inherently bad about the idea of Binding.current (i.e., if that's how Matz had done it, I wouldn't be arguing for it to be changed to Kernel#binding), but at best it's an even exchange and, therefore, inadvisable in my view.
-- David Black
I actually wrote a alias for binding called #here. Makes more sense to me and it's not a local variable name one would want to use (since "here" is always changing).
Onthe other hand, Binding.current does make better OOP sense to me. We should take some cues from .net if you ask me. They are very focused on good class models --I'm sure they would take this suggest approach rather then lumping it in Kernel. It also goes along better with ideas like Binding.of_caller. So I strongly advocate this for Ruby 2.0.
Method calls often look like local variables; that's not a problem in and of itself. Also, once you start renaming methods to free up variable names, it's hard to know where to stop (Array#length? String#upcase? Kernel#clone?). I don't think there's anything inherently bad about the idea of Binding.current (i.e., if that's how Matz had done it, I wouldn't be arguing for it to be changed to Kernel#binding), but at best it's an even exchange and, therefore, inadvisable in my view.
-- David Black
I actually wrote a alias for binding called #here. Makes more sense to me and it's not a local variable name one would want to use (since "here" is always changing).
Onthe other hand, Binding.current does make better OOP sense to me. We should take some cues from .net if you ask me. They are very focused on good class models --I'm sure they would take this suggest approach rather then lumping it in Kernel. It also goes along better with ideas like Binding.of_caller. So I strongly advocate this for Ruby 2.0.