--4dbc29ce_2a487cb0_107
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

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

--4dbc29ce_2a487cb0_107--