--- Daniel Brockman <daniel / brockman.se> wrote:
> Eric,
> 
> > With the String#to_* methods, you have to do something
> > like this:
> >
> > def parse_option(klass,option)
> >   if klass.equal?(String)
> >     option
> >   elsif klass.equal?(Integer)
> >     option.to_i
> >   elsif klass.equal?(Float)
> >     option.to_f
> >   else
> >     raise("can't convert #{option} to #{klass}")
> >   end
> > end
> >
> > With klass.from_s(str) methods, here is what you get:
> >
> > def parse_option(klass,option)
> >   klass.from_s(option)
> > end
> >
> > Which is duck-typed?
> 
> As David said, duck typing is irrelevant in these examples.
> 
> Duck typing is where you don't care about what class (Duck,
> WalkingQuackMachine) some given object is an instance of,
> but rather what messages (walk, quack) it responds to.

You are correct with that definition.  Which admittedly is the
common and original definition.  I was thinking of a slightly
different definition - don't compare a class (likely from an
object) against another specfic class.

For example, is this considered good duck typing?

klass = obj.class
obj2 = klass.new

vs. this:

klass = obj.class
if klass.equal?(String)
 ...
end

Maybe with the the original definition, neither of these are
duck-typed because you are using Object#class.  But, in the
spirit of duck typing, I'd say the first is good and the second
not duck-typed.

> How do you map that to the `parse_option' example?
> 
> I'd describe the difference between your two snippets by
> saying that the former uses *external* polymorphism (which
> is widely considered bad OO design) while the latter uses
> *internal* polymorphism (essential to good OO design).

I guess whatever you want to call it you'd agree that the
second example is better.



		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs