>
> >Plus "double dispatching" for
> >mixed type arithmetic.
>
> I use a variation of "double dispatch" myself (in a C++ program I wrote)
> where one can return function pointers as a replacement for the function
> returning it.
>
> But I do not think "double dispatch" has anything to do with the Int vs.
> Integer question.
>
In a sense it has, I think - unless we are talking about
two different things. Sooner or later, if one wants to marry
speed with safety, one has to admit operations between Ints
and Integers: do as much as you can in Ints, and if you cannot
then silently promote Int to Integer and continue.
Int would not have to be advertised as any official type, but
could exits internally at the implementation level.
Again, this is a classical Smalltalk approach, with this
difference that Smalltalk is typeless, so no problem
with advertised types.
Double dispatching in Smalltalk model, as I understand it,
goes like this (using Haskell keywords for integers):
Int, being a more primitive type, does not have to know how to
cope with Integer in the situations like this: Int * Integer.
So the method (*) in Int class has a hook for mixed arithmetic
with any, not necesserily Integer, object - it just dispatches
this expression again, after it sees that the other object is not
Int - but this time as "Integer * Int".
Some waste of processor cycles, but not much and most of
the further burden is taken away from supposedly fast Int and
given to Integer that do all the remaining checking, promotion
and execution. Operations Int * Int are still fast, but
overflow protected where the result is promoted to Integer
if necessary.
But thanks to double dispatching scheme, I could even define
my own fancy class: Quaternion, Spinor, or whatever and still be
able to do
Int * Spinor
providing that my Spinor class knows how to do Spinor * Int.
But I do not have to go back to Int class and redefine
and ruin everything that existed before.
Jan
