Hi --

On Sun, 2 Apr 2006, Trans wrote:

> <blockquote>
> It's not actually that practical, and such things end up making your
> code very much like C++ and Java.
>
> Ruby is smarter than that. Ruby can do more than that.
>
> Think in terms of what your object's required capabilities are instead
> of pretending that a class indicator is sufficient for that.
> </blockquote>
>
> While I understand you pointr Austin --obviously where talking Duck
> Typing here. But I think it is interesting to condier that this is some
> respect antithetical to OOP in general --I mean the reciever _is_ a
> specific type. And that reacieve detemine the functionality of the
> method call. It is sort of as if you were progamming in a more
> traditional functional language and _had_ to specifiy the type of the
> first argument, but never the remaining.
>
>  foofunc(  FooClass foo, clever, smart, stupid )
>
> instead of
>
>  foo.foofunc( clever, smart, stupid )

It's actually more like this:

   foofunc(object_that_responds_to_foofunc, etc.)

The fact that an object handles a message does not imply its class.
(I'm transliterating 'type' to 'class' as that seems to be what the
thread is actually about [as it usually is :-].)

> So why shouldn't any of the other participating objects have a
> selective effect too?

Because there's no applicable general notion of "a selective effect."
Each of these things is a different part of a system.


David

-- 
David A. Black (dblack / wobblini.net)
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black