From: Dave Thomas <Dave@...>
Date: 2001-04-17T02:45:08+09:00
Subject: [ruby-talk:13709] Re: methods and types

"Jish Karoshi" <karoshijish@hotmail.com> writes:

> So is it true that in this system the first thing that every
> function ought to do, in order to be robust, is check to see that
> certain operations have been implemented by the arguments that are
> passed to it?  Is the definition of a type in ruby or a language
> like it the set of all combinations of operations which an object
> has implemented?  Also, since the return types of functions are not
> defined, how does function A know that checking for the existence of
> function B in some parameter is enough to do something useful with
> the parameter?  Do I really need to check the type of every argument
> passed to my method and then check the return type of every method I
> call from those arguments?

Possibly the issue is broader than this.

First look at popular languages such as Java, where type-safety is
largely defined in terms on interfaces. If an object implements an
interface, then it is an acceptable parameter for a method that
required that interface, or for assignment to a variable of that type.

What has this gained you?

Well, you know that you can call the methods in that interface on the
passed object, and you will not get a runtime failure because they
don't exist.

Anything else? Not really, because the specification of type by
interface alone totally ignores semantics: I could define

   public class Dave implements Stack {
     public void push(Pushable o) {
       System.out.println("Refusing to push: I'm tired");
     }
     public Pushable pop() {
       return new PushableInt(99);
     }
   }

Type safe, but semantic gibberish.

Now, turn the question around. What do you gain by abandoning this
limited form of safety?

Well, we gain immense flexibility. Refactoring Smalltalk and Ruby is
trivial compared to (say) Java. Things just move around. There's no
need to jump through hoops to satisfy the compiler.

We gain substantial testability. You can construct mock objects very,
very easily, and test out code with far less overhead. You can test
objects before the classes they rely on are finished (or even
started). This ability to test partial classes also lends itself to
easier incremental testing.

We gain expressiveness. I don't know how to describe this one
objectively: I just know that I find this kind of code speaks to me
more directly: I'm dealing with objects, not object categories.

This is not a thing that can be argued rationally. I was a strong-
typing advocate for years, and was nervous when I used languages such
as Smalltalk and Ruby. However, I now find Java a very frustrating
language to use, and find myself writing higher-quality code in
Ruby. In the end, the only way to find out is to try it for yourself
and see. Write some Ruby code, and wait until you experience that
a-ha! moment. Then write some more code until you start developing an
idiomatic style. Get comfortable with RubyUnit or Lapidary. Then take
on a largish project, and see what you thing.



Regards



Dave