On Mon, Apr 21, 2008 at 6:00 AM, thufir <hawat.thufir / gmail.com> wrote:
> On Sun, 20 Apr 2008 19:52:35 +0900, Florian Gilcher wrote:
>
>  > The interesting thing about Generics in Java (and the point where they
>  > cannot make
>  > sense in ruby) is that they are only checked on _compile_ time. So, at
>  > runtime, all
>  > generic collections behave as a collection of Object.
>
>
>  It wouldn't be useful to have some sort test to make sure there's not a
>  type problem ahead of time?
>
>
>  -Thufir
>
>
>

Well if you search the archives you will see that I made the same
suggestion some years ago. It took me some time to understand why this
is not a good idea (because I am not the youngest anymore and I had a
*strong* Pascal and Ada
background some Java and C experience did not help either;).

Ruby is a dynamic language and features duck typing, this changes the
whole approach to design, you just tend to forget about classes and
types, and you tend to think about behavior. Now I do not say that
sometimes defensive programming is not in order but if you want to
check if an object passed into your method has a certain behavior than
checking for it's class simply is not the answer due to ruby's dynamic
nature, this is the maximum I could imagine useful:

def check_some_behavior object, message, *methods
    raise MyBehaviorError, message unless methods.all? { |m|
           object.respond_to? m }
end

but even here I would be very, very careful, e.g.

check_some_behavior x, "must obey but does not ARRRGGG ;)",
*MyLeanClass.instance_methods( false )

do you think this is maintainable? Imagine somebody adds a helper to
MyLeanClass or a more complex refactoring
is done, as e.g. factoring out of some of the behavior you want to
check to a mixin.

This is a dangerous straightjacket for Ruby.

Cheers
Robert


-- 
http://ruby-smalltalk.blogspot.com/

---
Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein