Double Dispatch in Eiffel
David Yost
>In <1992Nov13.2...@ncsu.edu>, originally posted only on
>comp.lang.eiffel (please see there for details of the problem),
>ech...@eos.ncsu.edu (EDWARD CRAIG HYATT) raises the ``double
>dispatching'' problem:
>
>> I'm having some trouble implementing double-dispatching in
>> Eiffel. I'm working on the solution to a homework problem
>> I assigned,
^^^^^^^^
>Here is a brief view on this subject. (As this is a homework
>assignment and I don't want to get into trouble with Mr. Hyatt's
>professor, I will only give an outline of the suggested solution...):
>
>2. If that is not the case, what this means from the perspective of
>object-oriented design is that you have identified a *new data
>abstraction*: figure pair. Then you should write the corresponding
>deferred class \fIFIGURE_PAIR\fR, and provide effective descendants for
>each useful combination
>The details are left to the reader, both because the question was
>homework-related of this problem and because it is pleasant to rediscover
>them for oneself. (I'll post them later if anyone feels it's necessary.)
Hi Bertrand,
I don't see how you would construct the pair object, which is
an instance of some subclass of FIGURE_PAIR (which subclass?), so
you can call pair.intersect(). Can you please elucidate?
Thanks.
--dave yost
Fergus James HENDERSON
>The starting point of the object-oriented method is (in the view of some
>of us at least) the identification of modules to types. That is to say, in
>looking for the best possible module structures (those which will be the
>most prone to reuse and the most likely to weather future changes of
>requirements, design and implementation decisions) the O-O
>designer decides to base every module on a type variant.
>
>Hence the classes FIGURE, SQUARE, CIRCLE etc. which are both modules
>(units of software decomposition) and types (descriptions of categories
>of run-time objects).
>
>This leads to the style of programming where every operation is of the
>form
> x.f (...)
>
>applying to an entity x defined of a certain type given by a class,
>and f is an exported feature of that class. At run-time x must be
>attached to a certain object O; the operation applies f to the object
>O, with the arguments given, if any.
>
>Dynamic binding guarantees that if x is polymorphic, that is to say if
>O may at run time be an instance of any one of several possible classes,
>then the appropriate version of f (the one for the class of which
>O is indeed a direct instance) will be applied.
>
>One of the major advantages of this approach is that it achieves what
>the SINGLE CHOICE PRINCIPLE: limit knowledge about
>exhaustive lists of alternatives (such as ``a figure is either a circle,
>or a square, or...'') to just one module. In contrast, non-O-O
>techniques usually result in many client modules having to know the
>list of all variants, which is a disaster for long-term software
>evolution, as such information tends to change, thus causing secondary
>changes in many modules.
>
>What now if there is a feature such as ``intersect'' or ``distance''
>that conceptually applies not to one but two figure arguments?
>
>There are two cases.
>
>1. If you have a strong feeling that you know the exact list of such
>two-argument operations (for example `intersect', `distance'), there are
>few of them, and you think that no others are likely to be added in the
>future, then use one-level dispatching and an explicit discrimination
>for the second level. The solution is of acceptable elegance and works well
>under the hypotheses given.
Assuming that the operation is symmetric with respect to its operands,
wouldn't it be better to use explicit discrimination for both levels?
Using a combination of one-level dispatching and explicit discrimination
seems terribly asymmetrical, and doesn't buy you anything. Even worse,
it violates the single-choice principle, because the knowledge about
exhaustive lists of alternatives is split into square::intersect,
circle::intersect, etc., instead of being in a single intersect
subroutine.
--
Fergus Henderson f...@munta.cs.mu.OZ.AU
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!
rix....@gmail.com
Cheers!
Larry
Simon Willcocks
My usenet archives only go back to 2007. I'll have to try Dejanews. ;-)
--
ROLF - The RISC OS Look and Feel on Linux.
http://ro-lookandfeel.blogspot.com/
http://sourceforge.net/users/simonwillcocks