Is Double Dispatch really object-oriented?

Hi,

I'm preparing a paper on this topic (I believe it isn't - that it
breaks encapsulation, for example). I thought I'd see if anyone has
any thoughts on this. I'll post a brief outline of what I'm thinking
shortly, along with an OO solution I've found.

The thing that caught my eye and made me skeptical about Double
Dispatch was that I've seen it talked about very highly in communities
that are somewhat hostile to object-oriented programming. (For
example, perl developers.)

Thanks,
Robb

robb wrote:

> The thing that caught my eye and made me skeptical about Double
> Dispatch was that I've seen it talked about very highly in communities
> that are somewhat hostile to object-oriented programming. (For
> example, perl developers.)

Double Dispatch is Objects-Oriented.

;-)

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

On 12 Oct 2006 14:56:01 -0700, "robb" <robb{}acm.org> wrote:

>I'm preparing a paper on this topic (I believe it isn't - that it
>breaks encapsulation, for example). I thought I'd see if anyone has
>any thoughts on this. I'll post a brief outline of what I'm thinking
>shortly, along with an OO solution I've found.

I see no reason why double dispatch breaks any rules. If an object P is passed
to a method of any other object Q, it is entirely appropriate for the Q to send
messages to P. If that message passes Q, it's entirely appropriate -- and ofter
very useful, to send a message back.

What is it about DD that troubles you?

--
Ron Jeffries
www.XProgramming.com
I'm giving the best advice I have. You get to decide if it's true for you.

"robb" <robb{}acm.org> writes:
> I'm preparing a paper on this topic (I believe it isn't - that it
> breaks encapsulation, for example). I thought I'd see if anyone has
> any thoughts on this.

Double dispatch is just a technique to work around the
limitations of languages that don't support multimethods. Object
orientation does not require dispatching solely on a single type. The
first standardized OO language was Common Lisp and its object system,
CLOS, supports multiple dispatch directly.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm{}spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

On 12 Oct 2006 14:56:01 -0700, robb wrote:

> I'm preparing a paper on this topic (I believe it isn't - that it
> breaks encapsulation, for example). I thought I'd see if anyone has
> any thoughts on this. I'll post a brief outline of what I'm thinking
> shortly, along with an OO solution I've found.
>
> The thing that caught my eye and made me skeptical about Double
> Dispatch was that I've seen it talked about very highly in communities
> that are somewhat hostile to object-oriented programming. (For
> example, perl developers.)

Do you mean multiple dispatch? Well, there is a wrong "OO-philosophy",
which considers methods as physical members of objects/classes and prefix
notation as sacred. In that sense MD is a heavy blow to them. But it is not
against OO. It is even not against sending messages. MD were a multicast
message, for that matter.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Ron Jeffries wrote:
>
> I see no reason why double dispatch breaks any rules. If an object P is passed
> to a method of any other object Q, it is entirely appropriate for the Q to send
> messages to P. If that message passes Q, it's entirely appropriate -- and ofter
> very useful, to send a message back.
>
> What is it about DD that troubles you?
>

I guess that one troubling aspect is that both classes have to know a
lot about each other's APIs. You have Q knowing things about P for
purely implementation reasons - not because it's called for in the
object / semantic model.

What do you think?

Patrick May wrote:
> Double dispatch is just a technique to work around the
> limitations of languages that don't support multimethods...

Thanks for helping differentiate the two. I like that description. It
helps me clarify my thesis: that Double Dispatch is a sub-optimal way
to solve the problem.

Dmitry A. Kazakov wrote:
> On 12 Oct 2006 14:56:01 -0700, I wrote:
> > The thing that caught my eye and made me skeptical about Double
> > Dispatch was that I've seen it talked about very highly in communities
> > that are somewhat hostile to object-oriented programming. (For
> > example, perl developers.)
>
> Do you mean multiple dispatch? Well, there is a wrong "OO-philosophy",
> which considers methods as physical members of objects/classes and prefix
> notation as sacred. In that sense MD is a heavy blow to them. But it is not
> against OO. It is even not against sending messages. MD were a multicast
> message, for that matter.
>

Ok - I get you. Personally, I find the differentiation between a
message recipient and message parameters to be useful.

I believe that the problems with DD aren't usually so apparent because
many of the examples of its use are fairly contrived. For example,
there's the common "Spaceships hitting Asteroids" example. It may not
be immediately obvious why Spaceships shouldn't know about Asteroids,
or vice-versa. But a mundane real-world situation highlights the
problem, I think:

So this is an actual issue I had in a software project: I had a bunch
of different classes that I wanted to render in different contexts.

The classes to be rendered might be things such as tables of data,
images, blocks of text, etc.

The "contexts" might be areas such as "html", "plain text",
"gui/swing", etc.

As far as I can see, this sounds like the classic set up that'd lead to
the DD solution - am I correct?

So now - I'm not a DD expert, but as far as I can tell, wouldn't the
implementation go something like this:


Client usage:

aTable.outputOn( anHtmlInstance ):


Implementation:

abstract class Drawable;
subclass Table;
subclass Image;

abstract class OutputSystem;
subclass Html;
subclass Postscript;

class Drawable:
void outputOn( os OutputSystem );
void outputAsHtmlTo( h Html );
void outputAsPostscriptTo(p Postscript );

class OutputSystem:
void outputMe( d Drawable );

(and then...)

class Table:
void outputOn(os OutputSystem):
os.outputMe(self);

class Html:
void outputMe(d Drawable):
d.outputAsHtmlTo( self );

class Postscript:
void outputme(d Drawable):
d.outputAsPostscriptTo( self );

(that sets up the Double Dispatch as I understand it. Then finally, we
have the code that does the work

hitting Asteroids" example. It may not be immediately obvious why
Spaceships shouldn't know about Asteroids, or vice-versa. But a
mundane real-world situation highlights the problem, I think:

So this is an actual issue I had in a software project: I had a bunch
of different classes that I wanted to render in different contexts.

The classes to be rendered might be things such as tables of data,
images, blocks of text, etc.

The "contexts" might be areas such as "html", "plain text",
"gui/swing", etc.

As far as I can see, this sounds like the classic set up that'd lead to
the DD solution - am I correct?

So now - I'm not a DD expert, but as far as I can tell, wouldn't the
implementation go something like this:


Client usage:

aTable.outputOn( anHtmlInstance ):


Implementation:

abstract class Drawable;
subclass Table;
subclass Image;

abstract class OutputSystem;
subclass Html;
subclass Postscript;

class Table:
void outputAsHtmlTo( h Html ):
#
# A bunch of code that makes many calls to the Html
# object, constructing a table in HTML.
#

etc.

- - - -

So - If I've got this right - I see lots of encapsulation and design
issues with this. For starters, a Table object - which is a Model
object - has to know about HTML - not just its existence, but its logic
and creation. And Postscript, etc.

I'm sorry about that garbled post - I have my Dell keyboard to blame.
Here it is, without the extra text that got re-inserted:


robb wrote:
> I believe that the problems with DD aren't usually so apparent because
> many of the examples of its use are fairly contrived. For example,
> there's the common "Spaceships hitting Asteroids" example. It may not
> be immediately obvious why Spaceships shouldn't know about Asteroids,
> or vice-versa. But a mundane real-world situation highlights the
> problem, I think:
>
> So this is an actual issue I had in a software project: I had a bunch
> of different classes that I wanted to render in different contexts.
>
> The classes to be rendered might be things such as tables of data,
> images, blocks of text, etc.
>
> The "contexts" might be areas such as "html", "plain text",
> "gui/swing", etc.
>
> As far as I can see, this sounds like the classic set up that'd lead to
> the DD solution - am I correct?
>
> So now - I'm not a DD expert, but as far as I can tell, wouldn't the
> implementation go something like this:
>
>
> Client usage:
>
> aTable.outputOn( anHtmlInstance ):
>
>
> Implementation:
>
> abstract class Drawable;
> subclass Table;
> subclass Image;
>
> abstract class OutputSystem;
> subclass Html;
> subclass Postscript;
>
> class Drawable:
> void outputOn( os OutputSystem );
> void outputAsHtmlTo( h Html );
> void outputAsPostscriptTo(p Postscript );
>
> class OutputSystem:
> void outputMe( d Drawable );
>
> (and then...)
>
> class Table:
> void outputOn(os OutputSystem):
> os.outputMe(self);
>
> class Html:
> void outputMe(d Drawable):
> d.outputAsHtmlTo( self );
>
> class Postscript:
> void outputme(d Drawable):
> d.outputAsPostscriptTo( self );
>
> (that sets up the Double Dispatch as I understand it. Then finally, we
> have the code that does the work
>
> class Table:
> void outputAsHtmlTo( h Html ):
> #
> # A bunch of code that makes many calls to the Html
> # object, constructing a table in HTML.
> #
>
> etc.
>
> - - - -
>
> So - If I've got this right - I see lots of encapsulation and design
> issues with this. For starters, a Table object - which is a Model
> object - has to know about HTML - not just its existence, but its logic
> and creation. And Postscript, etc.