On Sep 2, 5:50 am, pongba <pon... / gmail.com> wrote:
> Matz once replied on Cedric's blog that
>
> I am not against "method overloading", but it very easily leads to
> optional static typing in the language, which changes the language
> very drastically, since you need to specify "type" to overload
> arguments. Without well-thought design, it can "destroy" the language
> and its culture. I have not yet got that well-thought design of method
> overloading.
>
> This is a very general argument, what concerns me is that if, for
> instance, we have Matrix and Graph, and we'd like to be able to draw
> both of them (the two 'draw's would have the same semantic but
> different implementation logic), how 're we going to be able to
> overload draw on Matrix and Graph like what we do in C++ or Java:
>
> void draw(Matrix);
> void draw(Graph);
>
> One might argue that 'draw' should actually be a member function of
> Matrix and Graph so the problem is moot. But then there's two more
> problems:
>
> 1. if we can't modify Matrix or Graph, and writing a non-member 'draw'
> is the only thing we can do to extend the interface of them, and we
> actually can write 'draw' in terms of the public interface of Matrix
> and Graph.

There is a very good reading for support overloading, regardless. By
separating code based on interface it is much easier to override a
method. Without that one usually has to consider all the possible
interfaces in every override --even though one may only be interested
in a single one. OTOH, the downside of overriding is interface
collision --if more than one interface match, which method gets the
call? So it's actually easier to manage without it. And one can easily
work around the interface limitation by defining separate methods for
each case and having the main method as a simple dispatcher.

T.