Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: johnson@m.cs.uiuc.edu
Newsgroups: comp.lang.eiffel
Subject: Re: Multi-methods in Eiffel
Message-ID: <63400001@m.cs.uiuc.edu>
Date: 27 Jul 90 12:56:00 GMT
References: <11827@hydra.gatech.EDU>
Lines: 25
Nf-ID: #R:hydra.gatech.EDU:11827:m.cs.uiuc.edu:63400001:000:1368
Nf-From: m.cs.uiuc.edu!johnson    Jul 27 07:56:00 1990


I'm not from ISE, but I will comment on how to get the effect of
multimethods.  It is an easy (and, to me, standard) programming
technique called double dispatching.  It has a number of disadvantages,
but I consider them minor.  Kurt Hebel and I wrote an article on the
subject that appears in one of the recent issues of JOOP.

The basic idea is that you implement a binary operation like * by
sending a message to the argument.  The type of the original receiver
is encoded in the name of the message.  Thus, if you have 10 arithmetic
classes then you have ten messages of the form productOfInteger,
productOfReal, productOfMatrix, etc.  Each of the 10 classes has to
implement each of the 10 methods, so you end up with 100 methods.
Of course, you would have needed 100 multimethods, so it really
isn't any different.  You can generally eliminate a lot of the
multimethods using inheritance, but then you can do the same thing
with double dispatching, too.  The article gives details.

Multimethods and double dispatching are isomorphic.  One is a language
feature, the other is a programming technique.  In my opinion, the
need for selecting a method based on the type of more than one argument
is rare enough that it is probably not worth worrying about putting
multimethods in a language like Eiffel.

Ralph Johnson -- University of Illinois at Urbana-Champaign