"Markus" <markus / reality.com> schrieb im Newsbeitrag
news:1097553071.15571.670.camel / lapdog.reality.com...

>      But what about duck typing?  This was asked (IIRC) earlier on this
> thread but (again IIRC) not addressed.  The duck typing way would be to
> not depend on the class of the objects in the first place.  In the given
> example it would be something like:
>
>     puts x.class.to_s
>
> which works for all classes, old, new, borrowed, blue.

I tried to cover this issue but maybe it hasn't become clear enough.
Although duck typing is appropriate in many cases, there are cases where
it's not and in fact degenerates a design.  First it's important to note
that duck typing relies on the fact that all objects that can show up in a
certain context have a certain method (either as class or singleton
method) with the same signature:

# num must have #+(x) defined
def incr(num)
  num + 1
end

Now, while this is certainly a good idea for methods like to_s, to_i etc.
it's a bad idea for functionality that is special to a part of your
application.  For example, if you had a class Foo and defined methods
String#to_foo and Fixnum#to_foo etc. that might come in handy for a
certain lib or module and a lot of libraries do this, class interfaces of
standard classes get cluttered with methods totally specific to certain
parts of the application.  Also the likeliness of name clashes increases.

Note also, that you introduce dependencies from standard lib classes to
application classes which can be dealt with in Ruby because of its dynamic
nature, but which generally point in the wrong direction: it's usually
cleaner to have an acyclic dependency graph (certain languages need this
because otherwise you'll have compilation problems, read Lakos' "Large
Scale C++ Software Design" on the matter).

>      If the original poster is still reading, what is the real
> application?  Is there some reason you need to know the class, or do you
> just need to assure that the class has some behaviour?

That'd be certainly interesting to learn.

Kind regards

    robert