Chocolate [was Re: Python Books for 2002]

[Alex Martelli]

"Greg Ewing" <greg at cosc.canterbury.ac.nz> wrote in message
news:3AD50BB3.E71891A2 at cosc.canterbury.ac.nz...
> Ben Wolfson wrote:
> >
> > from Animals.Mammals import Human
> >
> > hungry_person = Human()
> >
> > So that the hungry_person can .consume() the comestibles.
>
> But the method of consumption depends on the class
> of the substance, so dispatching on it seems
> appropriate. Perhaps
>
>   substance.be_consumed_by(person)

We really need multiple-dispatch, because many
substances may be differently consumed by instances
of different concrete subclasses of Animal -- e.g.,
milk will be lapped up from a saucer by an instance
of Cat, but an instance of Human is unlikely to
.consume() it that way.

As is all too usual when multiple-dispatch is
really what's underlying our efforts (very often
the details of interactions between objects X
and Y depends on the concrete-classes of both
objects!), no single-dispatch solution is fully,
100% satisfactory.

Are we more likely to add different concrete
subclasses of Consumable in the future, or different
concrete subclasses of Consumer?  I suspect the
former is more likely -- new kinds of chewables,
drinkables, smokeables, etc, are likelier to get
developed and marketed than new kinds of Animal.

So, we should assume that a Substance (Consumable)
"knows about" all of its possible Consumer kinds
when the code for its methods is written, rather
than vice-versa.  Of course we should still factor
common code out to appropriate mixin classes, but
the dispatch on Substance still looks like the right
architecture.

Note that the architectural choice is determined
by a survey of likely foreseen use-cases, not by
vague aesthetic considerations:-).

Our predictions can be wrong.  If a starship lands
tomorrow, full of alien life-forms that are
interested in .consume()'ing our varieties of
Substance, we'll need to refactor... oh well!


Alex