Well, you can consider that the state of method includes its name =
(message), its source (the textual representation of the code), possibly =
its compiled representation (especially in JIT or caching systems), its =
comments and its parameters, if any.  Arguable, the receiver of a =
message is also part of a method's state, given that (in Smalltalk at =
least) one can refer to it using 'self'.
Having method objects makes powerful debuggers rather easier to =
construct, at least if one wants to stay consistently within a message =
passing 0-0 paradigm...

regards,
Bill

On Apr 30, 2011, at 11:25 AM, Michael Sokol wrote:

> I like Chad's explanation.
>=20
> I'd like to add that by definition, an object is a state and a =
behavior. In the case of a method object, it surely has a behavior, but =
I would question its state.
> On samedi 30 avril 2011 at 10:55, Chad Perrin wrote:=20
>> On Sat, Apr 30, 2011 at 04:35:15PM +0900, Josh Cheek wrote:
>>>=20
>>> I like that distinction, the message is :end_upcase, and the method =
is
>>> the code that is invoked. But I still think that considering the =
method
>>> itself to be a nonobject has no explanatory value (unless maybe =
you're
>>> knee deep in C), and requires lots of confusing explanations for it =
to
>>> make sense.
>>=20
>> Nah. The method is an expression -- often a complex expression =
composed
>> of multiple expressions. The object is what receives the message,
>> contains the method, and executes the method.
>>=20
>>=20
>>>=20
>>> IOW, the model is message passing, and when the message is received, =
it
>>> invokes the method. To get the method then, we must tell the
>>> interpreter, that we want the method that would be invoked by this
>>> message, and it returns it to us. I think that explains the =
behaviour
>>> quite nicely. Is there a model which involves non object methods, =
which
>>> explains something that this does not, and does not involve =
completely
>>> invisible complications?
>>=20
>> Within Ruby's model, you do not tell the interpreter to return the
>> method, nor to invoke the method. You tell the object to execute the
>> method. The object checks to see whether it can and, if so, executes =
the
>> method. If not, it lets you know (noisily). If the method exists, the
>> method is what returns something to you if you sent a message that
>> corresponds to that method.
>>=20
>> The model is explained quite simply:
>>=20
>> 1. You send a message to the object.
>>=20
>> 2. The object executes a corresponding method.
>>=20
>> The method is not something with which you ever interact directly, =
once
>> it has been defined. That's kinda the whole *point* of this object
>> model: you create classes to define objects with methods, then
>> instantiate those objects. You talk to the objects about what you =
want
>> them to do, and let them do the heavy lifting.
>>=20
>> "Object. Do this for me."
>>=20
>> "Yes, sir!"
>>=20
>> --=20
>> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org =
]
>>=20