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 ] >