From: Austin Ziegler <austin@...>
Date: 2003-11-20T15:47:06+09:00
Subject: Re: "stereotyping" (was: Re: Strong Typing (Re: Managing metadata about attribute types) )

On Thu, 20 Nov 2003 14:52:17 +0900, Thien Vuong wrote:
> I'm in the same position too. Love Ruby but cannot recommend it
> for team development w/o having the language provides some sort of
> intrinsic interface validation.

Again: why? Why do you need intrinsic interface validation? As
Michael Campbell noted, if a library writer isn't going to document
their code, what makes you think that they're going to put interface
validation in there?

That's what no one in this discussion has been able to explain. The
broad statement is made: "I need interface validation!" But no
convincing explanation as to why it's needed is made, either. OR why
interface validation is preferred to DbC or TDD -- both of which I
consider to be superior techniques to compile time type checking.

I've seen explanations like "I need it to protect myself" or "I
don't think my programmers can deal without it" or "I've tried it
before but it didn't work." None of these seems to have been done
with the full suite of Ruby techniques.

> I guess it's the truism that no language can satisfy everything -
> so just choose one that best fit the application. Lacking this,
> does seems to limit the applications that ruby could be used for -
> i.e. could be all implemented by one/two skilled programmers.

This does not follow. Yes, it's the current case with Ruby
development, but it does not follow that Ruby won't scale just
because it doesn't have static typing or interface validation.

[...]

> One thing I find interesting is respond_to? was frequently cited
> as a better way to handle the dynamism of Ruby than kind_of? -
> But, every faults that was found with kind_of? could be applied to
> respond_to? It also does 'name only' checking (name has no
> association with behaviour), could easily be overridden in any
> other way the programmer wanted to - in fact, I see method could
> be mangled much more easily than class, so the defects propagates
> both way.

Not really. You're right that the standard #respond_to? only
responds to a name. But while it shares the "name-based" defect,
it's less fragile because it doesn't restrict *classes* of objects,
speaking broadly. As noted: StringIO is not an IO, but it implements
all of IO. There are likely very good reasons as to why it's not a
subclass of IO (and IO is a class, not a module, so it can't be
mixed in). Therefore, checking for #<< (or better, simply *using*
#<<) is likely to be less fragile than checking for kind_of? IO.

> If we would believe that type checking is bad for Ruby, at least
> we should be honest in saying that Ruby does not offer type
> checking, as designed / or by its spirit, and programmers must be
> willing to deal with it in intelligent way - rather than offering
> a broken solution which automatically trigger the question from
> newcomer - "Oh it does not quite work - how would we fix this?"
> and trigger these kinds of flamefests on who is smarter than whom.

I don't think that anyone has suggested that they are smarter than
the other. Nor do I think that this has been a flamefest. IMO, TDD
is far more successful than object type checking.

> I do wonder what functional purpose does "kind_of?" serves now
> that it was severely denigrated in the language - should it be
> deprecated/ removed? since it is considered totally bad style to
> use.

I don't think that it's totally useless. I do think that it's of
extremely limited utility.

-austin
--
austin ziegler    * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2003.11.20
                                         * 01.31.09