From: Pillsy
Subject: CLOS and message passing
Date: 
Message-ID: <1175885319.982332.36510@l77g2000hsb.googlegroups.com>
So, this is something of a Lisp "Aha!" (or maybe object oriented
"Aha!") for me, but it's something I realized not so long ago. It's
obvious enough that I'm surely not the first to come up with it, but I
don't recall reading about it anywhere[1].

Everyone says that CLOS' generic functions generalize single-dispatch
"traditional" OO systems. But usually they seem to just mean that
where you used to dispatch on one object's class, now you just
dispatch on two or more.

But the way I see it, traditional OO with message-passing is already
doing double dispatch, like so:

(defgeneric send (self message &rest args))

(defmethod send ((self t) (message (eql :class-of)) &rest args)
  (declare (ignore args))
  (class-of self))

and so on for the other stuff you'd like to do. Being able to use EQL
specializers to make your messages keywords is kinda a neat gracenote,
but if CLOS didn't have that you could still define a class for each
message and keep an instance around one way or another. Either way,
appropriate macros, reader macros and the like can be used to brush
away the incidentally cumbersome syntax.

Not original, not obviously useful, but for some reason it makes the
relation between CLOS and other OO seem much clearer to me.

Cheers,
Pillsy

[1] Which isn't to say I didn't read about it anywhere. It's possible
I read it, didn't understand it, remembered just enough to recall the
idea when I did know enough to understand it, and *BOOM!*. If this is
actually in PCL or PAIP or something, I'd seriously love to be
reminded. :^)

From: Barry Margolin
Subject: Re: CLOS and message passing
Date: 
Message-ID: <barmar-97F01E.21345006042007@comcast.dca.giganews.com>
In article <·······················@l77g2000hsb.googlegroups.com>,
 "Pillsy" <·········@gmail.com> wrote:

> So, this is something of a Lisp "Aha!" (or maybe object oriented
> "Aha!") for me, but it's something I realized not so long ago. It's
> obvious enough that I'm surely not the first to come up with it, but I
> don't recall reading about it anywhere[1].
> 
> Everyone says that CLOS' generic functions generalize single-dispatch
> "traditional" OO systems. But usually they seem to just mean that
> where you used to dispatch on one object's class, now you just
> dispatch on two or more.
> 
> But the way I see it, traditional OO with message-passing is already
> doing double dispatch, like so:
> 
> (defgeneric send (self message &rest args))
> 
> (defmethod send ((self t) (message (eql :class-of)) &rest args)
>   (declare (ignore args))
>   (class-of self))

It's not really double dispatch if the MESSAGE parameter is only allowed 
to be a message name, not an arbitrary object that dispatches on its 
class like the SELF argument does.  The different constraints on these 
two parameters makes it clear that it's not symmetric.

-- 
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Pillsy
Subject: Re: CLOS and message passing
Date: 
Message-ID: <1175954769.305768.128710@y80g2000hsf.googlegroups.com>
On Apr 6, 9:34 pm, Barry Margolin <······@alum.mit.edu> wrote:
> In article <·······················@l77g2000hsb.googlegroups.com>,
>  "Pillsy" <·········@gmail.com> wrote:
[...]
> > But the way I see it, traditional OO with message-passing is already
> > doing double dispatch, like so:
>
> > (defgeneric send (self message &rest args))
>
> > (defmethod send ((self t) (message (eql :class-of)) &rest args)
> >   (declare (ignore args))
> >   (class-of self))
>
> It's not really double dispatch if the MESSAGE parameter is only allowed
> to be a message name, not an arbitrary object that dispatches on its
> class like the SELF argument does.  The different constraints on these
> two parameters makes it clear that it's not symmetric.

Right, I just found this way of looking at it clarified how CLOS
generalizes the ordinary OO model, not arguing that it doesn't
generalize it at all. I think the reason I find it more pleasing than
the competition is that it adds the symmetry you describe.

Cheers,
Pillsy