Austin Ziegler wrote:

> Well, the case of def x.foo is the only case where a Symbol by itself
> isn't going to be useful, really -- so maybe [Symbol, "Class"] is the
> better choice. Other manipulations of thse things in Ruby -- are done
> with the Symbol, and there's not a lot you can do to manipulate a
> Method object.

Symbols are really the only option here because of the overhead involved 
when creating a Method object for every def. I agree that it would only 
make sense in  private def other.method; end  cases, but I think  class 
<< other; private def method; end; end  is not too troublesome to use.

I am wondering why matz stays so silent on this. Are there issues 
frequently overseen? Would returning a Symbol instead of nil make a 
difference in terms of performance?