From: Christian Neukirchen Date: 2005-08-30T23:54:19+09:00 Subject: Re: Method behaves differently when called using #send "David A. Black" writes: > Hi -- > > On Tue, 30 Aug 2005, Christian Neukirchen wrote: > >> "David A. Black" writes: >> >>>> Because I felt they are different, as I said above. I admit fcall is >>>> not the best name, but very few people would use it. >>> >>> I guess I still think of the difference as a kind of mild "danger" >>> (i.e., danger to the receiver: its access rules will be violated). I >>> can certainly live without send! But "function call" just seems so >>> out of place. What about: send_abs (send absolutely)? I don't >>> know... I'll keeping thinking, if you're still taking suggestions. >> >> I very much like Austin's idea, to make #send not call private >> methods, but keep __send__ doing that. The latter should not be easily >> overwritable either. > > My problem with that is that the point of __send__ is to keep the name > send available for user-defined methods (the same logic that has led > to the freeing up of "id" through the creation of object_id). > > I think adding special significance to the __'s is too much of an > afterthought, and also would reintroduce the same problem for people > who want to write methods called "send". No, not really... if you want others to allow reusing "send", you can still call __fcall__ (no private). >> (And note that a fair number of classes define #send to do something >> different already. When #send and #send! do something entirely >> different, ugh.) > > I'm not sure what you mean. There is no #send! Assuming the #send (no private)/#send! (everything) approach was accepted, this could get very confusing. > David -- Christian Neukirchen http://chneukirchen.org