T
Trans
My feeling is that so much is changing that, when backwards
compatibility is critical, you're better off sticking to 1.8. If you
think the new features are more important than that, you're going to
have to bite the bullet and port your code to work on 1.9.
But why change something if you don't need to? The issue here is
merely semantic, #send vs. #funcall. So why break all those previous
uses of #send, if all we need to do is pick a different term to
prevent it? Is the semantics of #send that crucial? That's really the
crux of my argument: Why change #send if you are just going to offer
the same functionality in another straight-forward method like
#funcall.
Ruby has a general policy of giving long names to methods that
subverts formal OOP. So it really puzzles me that Matz would just pick
another simple term like 'funcall' (Lisp is great functionally, but
I'd certainly think twice before borrowing terms verbatim). If you
want something semantically "tight", I still think #send vs.
#instance_send makes the most sense. It clearly fits in with the rest
of the instance_xxxxx methods. But short of that, I just don't see the
point --just pick another name. Indeed, there may even be a better
term. For instance what about #respond? That has a similar meaning to
send and has a nice correspondence to #respond_to? Or if you prefer
something a little shorter/not quite so clearly correspondent, how
about #reply?
In any case, the bottom line is that, of all the choices (in order of
my preference): #send vs. #instance_send, keep #send and pick a new
term, #send vs. #send!, ... Matz' current choice is at the bottom. And
I think a lot of Rubyists agree.
T.
T.