From: Peter Vanbroekhoven <calamitas@...>
Date: 2005-08-31T02:54:08+09:00
Subject: Re: Method behaves differently when called using #send

On Wed, 31 Aug 2005, Eric Mahurin wrote:

> How about a version that allow classes to override send and
> call the original with super?  Or how about aliasing send?
> Here are some of the tests I showed in a previous message with
> this:
>
> a = A.new
> a.send(:do_sth) # => raises NoMethodError
> a.send(:send,:do_sth) # => raises NoMethodError
> a.instance_eval{send(...)} # => prints "hello"
> a.instance_eval{send(:send,...)} # => prints "hello"
>
> class A
>  alias _send send
>  def send(m,*args,&block)
>    super
>  end
> end
>
> a.send(:do_sth) # => prints "hello"
> a.instance_eval{send(:do_sth)} # => prints "hello"
> a._send(:do_sth) # => prints "hello"
> a.instance_eval{_send(:do_sth)} # => prints "hello"
>
> Notice you lose the dual functionality as soon as you do
> anything to send.  It looks like you can get it back by doing
> this:
>
> class A
>  private :_send
>  private :send
> end
>
> It is quite difficult to follow what is going on in the above
> examples and why it works.
>
> This is an interesting way of determining whether a method was
> called with or without a receiver.  But, I still think it isn't
> a good idea.  I think a method's functionality should be
> independent of that.

I never said it was a good idea, I was just pointing out that it is 
possible to do these kind of things, albeit using something that IMO 
should not be possible (which I made clear in another part of this thread, 
but which seems to be ignored by the man in charge) and in a not so 
robust way.

Anyway, my opinion is that private methods should not exist because they 
are mostly useless and because they make weird tricks like the above 
possible (and because they cause long threads about send!, fcall and 
__send__ --which are all weird choices-- and about giving send a hint of 
magic).

Peter