Hi, Josh

>> /* obtain the Function structure which wrap the function *func* */
>>  ¨ÂõîãôéïªæõîãßïâïâôáéîßÆõîãôéïî¨ æõîã ©»
>
> That isn't what you do in Ruby. In Ruby, you don't pass the function (or
> function pointer in this case), you pass a String or Symbol.

I wanted to show the simple example, so I used the function pointer.
My example, however, was not good. Sorry.

> Here is an alternative model: In Ruby, everything is an object. Methods are
> objects, hence the method class.
> http://ruby-doc.org/core/classes/Method.html But you can't directly access
> them, because Ruby doesn't make you use parentheses. So trying to access the
> method directly looks to the interpreter like you want to invoke the method,
> since that is pretty much always what you want to do. But every now and
> then, you want to actually get the method, and so Ruby gives you a getter
> method that knows how to do that, and it's aptly named "method".

We can think a method is an object but we can't touch it, as you said.
Then, why do we need to think that it is an object? We need not
consider a method as an object, because we cannot access the object
which represents the specific method even if a method is an object.

If you think that the Method object represents the specific method
directly, the idea is not good. The Method object knows not only the
method but also the receiver, so there are many different Method
objects that refer to the same method. Please see the following
example.

---
 class C
   # the method *meth* is defined in a class *C*
   def meth
     puts "aaa"
   end
 end
 c1 = C.new

 # we can get the Method object which refers to the method C#meth
 meth_obj1 = c1.method :meth
 # this object knows the receiver
 meth_obj1.receiver == c1 #=> true

 # other Method object which refers to the same method
 meth_obj2 = C.new.method :meth
 # both meth_obj1 and meth_obj2 refer to the method C#meth,
 # but these objects is not equal
 meth_obj1 == meth_obj2 #=> false
---

In the example, we can see these Method objects don't represent the
method C#meth directly. Then, how do we obtain the object which
represents the method C#meth directly? No, we can't. There is no way.

That is why we cannot identify the Method object with the specific method.

>> I think that Ruby users need not know how a Method object wraps a
>> method, but they should know the fact that a Method object wraps a
>> method and a method is not a object.
>>
> Why? Is that even a Ruby thing? It seems so out of place to me that I would
> assume it is an MRI implementation detail. Do the other Rubies do it that
> way? If so, is it just for efficiency where they are all objects as soon as
> we need them to be, but keep it lazy and don't bother turning them into
> objects until such time as we know we need it?

Yes. It is a Ruby's concept that a method is not an object.

Please see Ruby Draft Specification:
http://www.ipa.go.jp/software/open/ossc/english/ruby/ruby_draft_specification.html
Although this document is still draft version, it is a good document
for us to learn the Ruby's fundamental concepts. In sec.6.3, they
write about a method. Quoting from it:

"A method is a procedure which, when invoked on an object, performs a
set of computations on
10 the object. A method itself is not an object."

Using any Ruby implementation, Ruby users should think a method itself
is not an object.

-- 
NOBUOKA Yuya