From: dblack@...
Date: 2007-09-02T22:32:08+09:00
Subject: Re: How does ruby handle overloading?

Hi --

On Sun, 2 Sep 2007, pongba 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.
>
> 2. if '1' doesn't matter (because in ruby we actually can add new
> methods to an existing class), then can you please give another more
> qualified example?

I am a great believer in 'extend'.


module MatrixEnhancements
   def draw
     ....
   end
end
m = Matrix.new.extend(MatrixEnhancements)

This lets you endow specific objects with what they need, and you
don't have to change classes globally. It is, in my opinion, a much
under-utilized technique.


David

-- 
* Books:
   RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
   RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
     & consulting:  Ruby Power and Light, LLC (http://www.rubypal.com)