[ruby-talk:12531] Re: Math package

> From: ts [mailto:[e-mail]]
[...]
> C> The real interesting point is of course the multi-method lookup 
> C> - the point where type-based overloaded functions are both slow 
> C> and muddled with Koenig lookups etc.. (the following leaves
> C> out the question on how to generalize module inclusion but this
> C> can probably be done coherently as well) 
> C> The basic strategy probably should be lexicographic over the mtype
> C> components in our example an double object since this strategy
> C> is simple and coherent. In our example this would be 
> C> [Float,Float],[Float,Numeric],[Float,Object], [Numeric,Numeric]
> C> ,..., [Object,Object] 
> 
>  You can have multi-dispatch if you write
> 
>    class Object2
>       def mself(Float a, Float b)
>           # work with 2 float
>       end
>    
>       def mself(Float a, Numeric b)
>           # work with float and numeric
>       end
>    
>       def mself(Object a, Object b)
>           # work with all other objects
>       end
>    end
> 
> 
>  This can be easily extended to a module.
> 
True, but type based overloaded functions and multi-dispatch 
are more or less equivalent - by using the (<x,y>)  notation
you could also write pr(x,y) you put the responsibility which 
parameters can be overloaded back into the court yard of the
caller.
This speeds up the method loop-up and seems much cleaner
(and no ambiguities of Koenig lookups once you settled on the 
lexicographic search path) and type based overloading per-se
does not have the anal distinction of object and multi-object
at all. Admittedly the extra complexity of object versus
multi-object is also the achilles tendon of this concept.

If you look at the example of arctan2 in Math (this works
for Float's but it makes sense to override this for Complex's) 
its clear that x.arc2tan(y) is completely unacceptable since is
not symmetric in x,y - so you have to turn this into a function
of three parameters with one unnecessary (unused )self Object
variable. To me once forced into swallowing ``x.abs'' I see no
reason why  ``pr(x,y).arctan2'' or ''(<x,y>).arctan2'' should
be any different. 
I also don't like the fact that Object2 < Object (but I am
probably just paranoid here) and doubt that you can play the
same functional programming games if forming multi-types of
singleton classes were  possible - that is
Object2
    def mself(A,B)
	 # return an multi-object of mtype
       #  X = Class::IsPair A , B in my notation 
    end
end	
where A and/or B are singleton classes - i.e. 
A (or/and B) = ObjectSpace._id2ref (  class << x; id ) 
for some Object x.

That said it is probably possible to write a Multi-object
extension with the ``pr''-notation (but I have no idea 
how difficult this would be in particular how to make
this really fast.)

Christoph