Re: Module#define_method "send hack" fails with Ruby 1.9

On 2/22/06, George Ogata <[e-mail]> wrote:> [e-mail] writes:>> I'm still not happy about #funcall. How is one supposed to remember>> which (#send or #funcall) is which? There are a few things in Ruby>> where "you just have to memorize it" -- like the true/false arguments>> to #instance_methods, or the differences between Proc.new and lambda.>> I've always felt that these are soft spots in the language.>> #send/#funcall seems to me to be in the same category.> #funcall breaks the rules. That makes it "fun". ;-)
>> Also, are methods now also called functions? That would be a pretty>> huge change in terminology.> I agree. I suspect it was named after `rb_funcall', though.>> FWIW, I'm not a fan of the new #send/#funcall thing either, but more> because it simply breaks too much. Even if it's slated as a 2.0> release. rubygems and instiki are two things I've tried recently.>> Instead of renaming #send to #funcall and reimplementing #send in a> crippled way, wouldn't it be better to leave #send alone, and just add> a new method that respects the method's protectedness/privateness?>> No, I don't have a name for it.
#safe_send/#__safe_send__ ?
Quite honestly, I use #__send__ for a lot of things and I really don'twant to be bitten by a change here. I really like that "private" is anadvisory in Ruby, not a hard-and-fast rule.
If we do change #send/#__send__, I would rather have a better name than#funcall (and is there #__funcall__?). Maybe:
#unsafe_send/#__unsafe_send__ ?
What if we changed #instance_eval to specifically take a symbol:
  foo.instance_eval(:private_method, *args)
-austin--Austin Ziegler * [e-mail]               * Alternate: [e-mail]