oop's multi-dispatch

6.5: adda/oop/multi-dispatch/ working with obj'c:
[6.17: intro:
. according to the wiki,
the term"multi-dispatch refers to
something other than what I assumed it to be
so, I will now explain the diff's .

. everybody agrees on how polymorphism happens
when there is only one argument:
when you write f(x) you mean
x can be any type as long as
x's type defines a function f .
. you don't really know which procedure or method
is being used to define the function f
until you ask x what its type is,
then you use the f-procedure defined by that type .
. that is called dynamic dispatch;
the term "(dispatch) is being used in the same way
as "(taxi dispatcher),
whose decision of which taxi to send
depends on which taxi is free and closest;
likewise, a function call dispatcher
determines which procedure to send the arg to,
and bases its decision on
both the function name,
and the argument's type .

. if the arg is binary,
then a multi-dispatch system has to find
a procedure that is typed for that particular
combination of arg types;
and most such systems use function overloading;
ie, they overload a function's meaning;
there are many types of cars and motorcycles;
and how a collision turns out
depends on both types;
so then, for each type combination,
you have to define a new procedure
for the car-motorcycle collision function;
that means, for example,
that every time you create a new type of motorcycle,
you have to define as many new collision procedures
as there are types of cars .

. the multi-dispatch system I have in mind
does not use overloading;
rather it expects multiple args to share some supertype;
so, for the cars and motorcycles example,
they could simply share the physics type;
which defines its members as having
a mass and a velocity;
the collision procedure asks both arg's
for their mass and velocity
and then calculates new velocities for each .
. it then sends each arg a message
to change itself to the new velocity,
which each can do with its own version of
a velocitychange(x) procedure .

. that was a simple case because the multi-arg function
could be reduced to a multiple of single-arg functions;
a more complicated case can be found in numerics,
where a binary operation doesn't resolve into
2 unary operations;
. for example, say you had a numeric supertype
that includes only reals and ints;
# it can be overloading the addition function:
+(int, int),
+(real, real)
+(real, int),
+(int, real) .
# or it can use coercion:
it checks to see if types differ,
and then converts one
so both are the same type:
+(int,real) then means a call to
it then checks whether the destination
is able to accept a real,
or if the destination has a function for
converting a real to its own type .

. now lets say another type, Rational,
is declared to be a subtype of numerics;
this means the supertype procedure for
handling binary operations
has to be updated:
# overloaders then have many more cases to deal with:
x {int,real,rational}.
= 9 cases instead of 4 .
# coercers have another rule to add:
if types differ, then convert ... to ...:
{int,real} to real
{int,rational} to rational
{real, rational} to real .

. in the case of numerics there is a limit to this:
every imaginable subtype of numeric
can be expressed as subtypes of
just these subtypes:
{int, real, rational, complex}
x size-{1,2,4,8byte, huge};
so, for example,
we can declare rainbow to be a subtype of real,
and then the numeric supertype can
-- without ever knowing about rainbows --
see from its type declaration
that it must have a
convert rainbow to real procedure;
and, if a destination is type rainbow,
it again knows from the rainbow declaration
that this destination
has a real assignment procedure .
[6.8: 6.17:
. as part of developing for mac,
obj'c features the usual dynamic dispatch .
. the sort of multi-dispatch I have in mind
would fit within mac's type-tagging system;
so for instance,
numerics would have 2 type tags:
# one says it's a subtype of mac's NSobject,
# another is private and indicates
which subtype of numeric it currently is .]