On Sat, Apr 30, 2011 at 12:55 AM, Chad Perrin <code / apotheon.net> wrote:

> On Sat, Apr 30, 2011 at 02:15:15PM +0900, Chad Perrin wrote:
> > On Sat, Apr 30, 2011 at 08:01:48AM +0900, Josh Cheek wrote:
> > >
> > > That's because methods are invoked by default, as I already stated.
> > > You need a line that evaluates to the method, not to nil. Your issue
> > > isn't with the objectivity of methods, it is with how you access
> > > methods.
> > >
> > > # this is evaluated
> > > puts                            # => nil
> > >
> > > # now we have a reference to it
> > > puts = method :puts             # => #<Method: Object(Kernel)#puts>
> >
> > That's a wrapper -- not the method itself.
>
> A little elaboration . . .
>
>    class String
>      def end_upcase
>        self.split[-1].upcase       # This Line: Method
>      end
>    end
>
>    'foo bar baz'.end_upcase        # String Before Dot: Object Literal
>                                    # Thing After Dot: Message
>
> The string of characters "end_upcase" in the above isn't even a method,
> per se; it's a message, sent to the object that is the return value of
> the expression preceding it.  The return value of an object literal is
> the object literal.  The return value of a nonliteral object is the
> object reference stored under whatever label/variable you use for it, or
> the object that is returned by some other form of expression.
>
> So . . . it is not only the case that methods are not objects; it is also
> the case that the thing you probably think of as a method is not a
> method.  It's a message, being sent to an object, which in turn probably
> has a method defining how it responds to that message.
>
> --
> Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
>

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.

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?