On 3/29/07, Alex Young <alex / blackkettle.org> wrote:
> David Vallner wrote:
> > Alex Young wrote:
> >> I think of them like this:
> >>
> >> - A method is a message to which an object responds.
> >> [snip]
> >> By this definition, it is possible for an (object,message) pair to be
> >> viewed as a function.
> >
> > Of course, the very existence of CLOS makes this definition a little
> > vague. Since then, it would be the tuple of a "message" and all the
> > objects (values really) it's "sent to" (which, in CLOS, it quite isn't,
> > since IIRC, the multiple-dispatch mechanism doesn't have to use the most
> > specific class of either argument if it wouldn't lead to a match), and
> > things go all manners of pear-shaped, making a method really only a
> > tuple of a message name and its arguments, where I can't really see the
> > distinction between that and a function name and its arguments. (Based
> > on your definition only.)
>
> Absolutely agreed.  "Method" and "function" needn't be (and as you've
> shown, aren't) exclusive terms.
>

I have always thought of method as a function that takes an implicit
argument: the object self.

I imagine that the thing that made people invent OO was the basic
problem that often comes in procedural programming: I got this bunch
of data and this bunch of functions designed to operate on that. I
have to pass the data to every function every time I call it. Even it
I put it into a single structure I still have to pass the structure
around. Why cannot I just use some syntax that binds the function to
the data?

Of course, once the implicit argument is present one can also
implicitly include a dispatch table that defines what the function
actually does on the particular object. And talk in terms of abstract
views that no longer make the method look like a function. But it is
still a mental or syntax shortcut I guess.

But yes, shortcuts that clarify things that were hard to understand
before are immensely useful.

Thanks

Michal