double dispatching

Hi,

I don't understand very well what the double dispatching (in the magnitude
hierarchy) protocol is for. Could someone give me some pointers to some
information about this?

BTW, I'm using VW.

Take the message + as an example:

For Fraction it reads
^aNumber sumFromFraction: self

For Integer it reads
^aNumber sumFromInteger: self

What happens here is a classic example of double dispatching. All number
class instances should be possible to add to each other. So when adding an
Integer to a Fraction, the method sumFromInteger: on Fraction is eventually
invoked through double dispatching. The specific details on how to add an
Integer to a Fraction are implemented in this method. Note the compact, and
easy to understand, syntax of this method. Other types of numbers implement
this method different, as the logic needed to do the calculation is not the
same.

Try to debug (select and choose 'Debug it') the following statement to see
the double dispatch in action:
1 + (1/2)


Double dispatching can be used to make a system easier to extend. A prime
goal for developers should be to make systems where you do not have to
modify existing functionally in order to introduce new functionality. If you
were to introduce your own number-type, you could subclass Number and
implement the various sumFrom...: methods.

To get everything up and running, you might also need to add new methods to
the existing number classes. These methods would typically be named
"sumFrom<YourNewNumber>:". Note that you should not need to modify any
existing methods in the Number hierarchy, only add new ones.

Adding new methods to base classes is of course fully supported in
well-designed languages. In addition, the various source control systems
handles this so that you do not need to change the original class. You
simply "extend" it in your own component.

Double dispatching, as used in the Magnitude hierarchy, helps to avoid long
methods that must test for type (class) of the objects handled. If the
system had "Case"-style methods to handle adding numbers, you would need to
modify the methods directly to handle your new number-class. The next
developer that comes along, would need to modify your code again, and so on.
Removing your number type when it is discovered that it is no longer
needed, would be very difficult.

"So what? The number hierarchy works in other languages also." Well, if you
follow the design described above, also for your enterprise-application with
20 developers, there is a higher chance that you will succeed. Smalltalk
does not force you to partition your application like this, but gives you
various hints where to go, and provides the tools to do it.



There is no need for a "Case"-statement in a proper OO-language. In fact it
should be avoided.



Runar Jordahl
http://www.smallwalk.com/

Fernando Rodríguez wrote:
> Hi,
>
> I don't understand very well what the double dispatching (in the magnitude
> hierarchy) protocol is for. Could someone give me some pointers to some
> information about this?
Runar gave a good explanation. A google on "double dispatching
smalltalk" turned up several examples. This one was good
http://www.object-arts.com/Educatio...bleDispatch.htm

All the examples deal with Arithmetic. Anybody have an example from some
other domain?

On Wed, 12 May 2004 18:48:39 +0200, "Runar Jordahl" <ssa2ds> wrote:

>Try to debug (select and choose 'Debug it') the following statement to see
>the double dispatch in action:
>1 + (1/2)

OK, I tried it out, but I'm afraid I got lost with the details and still don
't
get the big picture.

I couldn't see any explicit test of the type of any object, so how does
Smalltalk 'know' which method to call? O:-)

My book (On To Smalltalk) doesn't mention this, and I tried searching for
double dispatch in several books from the 'free smalltalk books' site but
didn't find anything. However, this stuff seems important and I'd like to ge
t
it. Is there any tutorial or article about this that explains it 'as if my
mind had been damaged by C++'? O:-)

>"So what? The number hierarchy works in other languages also." Well, if you
>follow the design described above, also for your enterprise-application wit
h
>20 developers, there is a higher chance that you will succeed. Smalltalk
>does not force you to partition your application like this, but gives you
>various hints where to go, and provides the tools to do it.
>
>
>
>There is no need for a "Case"-statement in a proper OO-language. In fact it
>should be avoided.

But case statements aren't only used for dispatching on the type of an objec
t,
also on the value. How do you handle this sort of thing in Smalltalk?

Hi Fernando...

the basic idea is simple. Say you have two types A and B, and an operation
you have to perform that should work with A op A, A op B, B op A and B op B,
but the actual implementation must be different for all combinations.
Apparently you need 4 implementations in this simple case. Double
dispatching is a way to do this without checking each type explicitly.

Here is how it goes:

First, you apparently have to define
A>>op: anAOrB
and
B>>op: anAOrB

Now, your As and Bs respond to op:.
Now the double dispatching implementation:
A>>op: anAOrB
"we know WE are an A!"
^anAOrB opWithA: self.

and
B>>op: anAOrB
"we know WE are a B!"
^anAOrB opWithB: self.

Now we are no better so far, we just need more methods in A AND B, namely
opWithA: and opWithB:
Well here they are:
A>>opWithA: anA
A>>opWithB: aB
B>>opWithA: anA
B>>opWithB: aB

Not better? - well, we solved our problem!
In each of these method, we know what WE are (self) and what type the
argument is!

A>>opWithA: anA
"we are an A and arg is an A"
A>>opWithB: aB
"we are an A and arg is a B"
B>>opWithA: anA
"we are a B and arg is an A"
B>>opWithB: aB
"we are a B and arg is a B"

This is all about double dispatching.
In more complicated scenarios with more types involved, you might get even
triple or higher dispatching, but the trick is always the same, you leverage
on the fact that you as the receiver of a message know YOUR type and send an
appropriate "typed" message to the argument.

HTH

Ciao

...Jochen

Try this book:

Design Patterns Elements Of Reusable Object-Oriented Software
Erich Gamma
Richard Helm
Ralph Johnson
John Vlissides
ISBN 0201633612
publisher: Addison-Wesley

-- based on Smalltalk examples.
I've used it to learn design patterns (and specificaly Double Dispatch).


or even:
The Design Patterns Smalltalk Companion  (1998)
Sherman R. Alpert (IBM T.J. Watson Research Center)
Kyle Brown (Knowledge Systems Corporation)
Bobby Woolf (Knowledge Systems Corporation)
ISBN 0-201-18462-1
publisher: Addison-Wesley

-- based on C++ examples


HTH

Ivaylo

"Jochen Riekhof" <jochen-r@orbotech.com> wrote in message
news:40a3708e@news.totallyobjects.com...
> Hi Fernando...
>
> the basic idea is simple.

Indeed, with the example you gave - it IS simple.  Thanks, I finally
understand this pattern.

Elliot

"Jochen Riekhof" <jochen-r@orbotech.com> writes:

> Hi Fernando...
>
> the basic idea is simple. Say you have two types A and B, and an operation
> you have to perform that should work with A op A, A op B, B op A and B op 
B,
> but the actual implementation must be different for all combinations.
> Apparently you need 4 implementations in this simple case. Double
> dispatching is a way to do this without checking each type explicitly.
>
> Here is how it goes:

Jochen - thank you for this great example.  I've always had a decent
understanding of double-dispatch and have even used it at times, but
this lays things out perfectly explicitly.  Wonderful!

--
Jason Dufair - jase@dufair.org
http://www.dufair.org/
"Time flies like an arrow. Fruit flies like a banana."
-- Groucho Marx

Fernando,
 
>
> But case statements aren't only used for dispatching on the type of
> an object, also on the value. How do you handle this sort of thing in
> Smalltalk?

Just as a matter of interest can you think of a real example where you
actually need to switch on the "value" of something where it isn't
really being used as a type?

This idea about the abuse of switch/case statements in OOP languages is
one of the "bees in my bonnet" (i.e. something that gets me wound up)
partly because, when I first started in Smalltalk, I couldn't see how
any *real* language could do without them. When I finally "got it" I
think I understood much better how Object Oriented Programming should
be done.

There are *some* situations where a switch can be useful but these
often only occur when interfacing with other non-OOP systems. For
example, if you were interfacing some Smalltalk to the Windows message
loop you might you need to switch on the WM_xxx messages coming in from
the OS. You'd do this in order to dispatch to a particular Smalltalk
method to handle the messages (I apologize to non-Windows programmers
here). If you have Dolphin Smalltalk you can see an example of this
sort of switch in the View>>dispatchMessage:wParam:lParam method.
You'll see that it looks up a Smalltalk selector for the message and
then #perform:'s it.

Even so, the true OOP solution for this example might be to lookup
message objects whose class was based on on the value of the WM_xxx
message and double dispatch via these.

There have been several discussions in this group in the past about
adding a switch/case statement to the Smalltalk language or even just
to the class library (the latter is almost trivial to do). However, I
would oppose this on the basis that the few times it would be
convenient to use are greatly outweighed by the fact that Smalltalk
newbies would no longer be forced to think about the right way to
approach the problem.

Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

Andy,

Your explanation matches conventional wisdom but I think that the need
for case-like or nested conditional statements is not quite so
negligible. Take, as an example, a function whose definition depends on
the interval containing the value of the argument such as the sign
function (-1 / 0 / 1 for x < 0 / = 0 / > 0) - and many real-life
situations belong to this category. How would you do this naturally in a
way that does not use nested conditions?

Ivan

Andy Bower wrote:

> Fernando,
>
> 
>
> Just as a matter of interest can you think of a real example where you
> actually need to switch on the "value" of something where it isn't
> really being used as a type?
>
> This idea about the abuse of switch/case statements in OOP languages is
> one of the "bees in my bonnet" (i.e. something that gets me wound up)
> partly because, when I first started in Smalltalk, I couldn't see how
> any *real* language could do without them. When I finally "got it" I
> think I understood much better how Object Oriented Programming should
> be done.
>
> There are *some* situations where a switch can be useful but these
> often only occur when interfacing with other non-OOP systems. For
> example, if you were interfacing some Smalltalk to the Windows message
> loop you might you need to switch on the WM_xxx messages coming in from
> the OS. You'd do this in order to dispatch to a particular Smalltalk
> method to handle the messages (I apologize to non-Windows programmers
> here). If you have Dolphin Smalltalk you can see an example of this
> sort of switch in the View>>dispatchMessage:wParam:lParam method.
> You'll see that it looks up a Smalltalk selector for the message and
> then #perform:'s it.
>
> Even so, the true OOP solution for this example might be to lookup
> message objects whose class was based on on the value of the WM_xxx
> message and double dispatch via these.
>
> There have been several discussions in this group in the past about
> adding a switch/case statement to the Smalltalk language or even just
> to the class library (the latter is almost trivial to do). However, I
> would oppose this on the basis that the few times it would be
> convenient to use are greatly outweighed by the fact that Smalltalk
> newbies would no longer be forced to think about the right way to
> approach the problem.
>
> Best regards,
>
> Andy Bower
> Dolphin Support
> www.object-arts.com
>