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.
> 
> 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: 
>> On Sat, Apr 30, 2011 at 04:35:15PM +0900, Josh Cheek wrote:
>>> 
>>> 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.
>> 
>> 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.
>> 
>> 
>>> 
>>> 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?
>> 
>> 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.
>> 
>> The model is explained quite simply:
>> 
>> 1. You send a message to the object.
>> 
>> 2. The object executes a corresponding method.
>> 
>> 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.
>> 
>> "Object. Do this for me."
>> 
>> "Yes, sir!"
>> 
>> -- 
>> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
>>