From: patrick-may@... (Patrick May)
Date: 2002-09-17T04:52:07+09:00
Subject: Re: not grasping the method overloading/multi-dispatch thing

Philipp Meier <meier@meisterbohne.de> wrote in message news:<20020916141154.GE17997@o-matic.net>...
> Coming from a java background if do not feal comfortable with Mixins,
> yet. Altough I must admist this a clever use of them. Nevertheless I fear
> a clash of method names if more than a few mixins are used on business
> methods. Imaginge you want to extend to example by a to xml method.
> Accidently you name the tag method "tag" like the one for HTML. (Assume
> the XML aspect is defined in another place than the HTML.) This could
> lend to real confusion, IMHO. I know, I know there are Unit Tests that
> should catch this but I stell consider it a slight smell.

Pushing methods into the same namespace by default definately leads
you towards having name conflicts.  A friend of mine said "the problem
with globally unique identifiers is there just isn't enough of them"
:-)

Jokes aside, the point of this techinique is to reduce complexity
first.  The kinds of bugs you get from complexity are real pains, and
finding existing bugs is a pain as well.

I've run into namespace conflicts like what you described before, but
always ahead of actually coding the methods.  What has happened is
that I've gotten frustrated when trying to think of a name for a new
method.  When that happens, I try to look for ways of splitting up the
data / methods into smaller objects.  In the thread's example, you
could retain the StringOutput and IntegerOutput objects, and overload
String and Integer with:

    class StringOutout
        def to_html
            ....
        end
    end

    class String
        def get_format
            StringOutput.new( self )
        end
    end

    class IntegerOutout
        def to_html
            ....
        end
    end

    class Integer
        def get_format
            IntegerOutput.new( self )
        end
    end

The only thing I look for is less code, fewer arguments, and a smaller
overall application.  I think that conditionals on classes are
redundant b/c the OO enviroment _automatically_ performs conditionals
on classes for you, only looking in the right classes for the method. 
Thus, I think you always get less code by letting the enviroment
handle those conditionals.

~ Patrick