From: Trans Date: 2007-08-08T01:03:14+09:00 Subject: Re: #send in 1.9 On Aug 7, 7:00 am, Bira wrote: > On 8/2/07, ronald braswell wrote: > > > Will there be a compatability flag to allow 1.9 to act like 1.8 for cases in > > which backwards compatability was broken? That way you could take advantage > > of new features w/o having to rewrite an existing codebase all at once. > > 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.