From: Peter <Peter.Vanbroekhoven@...>
Date: 2003-11-21T23:53:49+09:00
Subject: Re: Partial Euphoric Type Checking (Super Duck!?)

> > you see we have a problem here. it doesn't matter what methods are
> > implemented, because '>' for a String and '>' for a Numeric don't DO
> > the same KIND OF thing. the operators are overloaded. so respond_to? isn't
> > enough. we end up having to think about what will be passed to those
> > responding methods as well -- we end up having to ask not only, can you
> > handle the responsibilities? but can you handle the arguments? (sounds like a
> > thread i know ;)
>
> So we'd like the code we write to tell us when we've screwed up, but a
> typing system is basically not smart enough, because type alone does not
> determine functionality.
>
> I guess we're back to unit testing.
>
> Or am I over-simplifying?

My view is that neither testing for the presence of a method with a
certain name, nor doing that as well as testing for type of the
parameters, is a sufficient type check. Then sin example from the pickaxe
shows this: two methods with exactly the same signature in any aspect you
can measure without delving into the code. Still they do different things.
Even if every method does exactly as it promises, you can't find out the
promise by looking at method signatures.

Now this was never a problem in a language like Java, because ancestry
told you about the promises a method makes. OK, promises are meant to be
broken, but even in ruby code it's a problem if a method doesn't do what
the caller expects it to do. Not that Java is ideal, especially the fact
that types and classes are the same, except for interfaces. There are
languages that have two types of classes: abstract ones, providing a
hierarchy of interfaces, and implementation classes providing an
implementation for a set of interfaces. You can't inherit from
implementation classes, you can only include its code (mixin-like). This
is full separation of type and class. And implementing an interfaces holds
a promise as to the methods in it. I think it should be doable in Ruby to
have something like that, adapted to ruby's dynamical context. But it
includes more typing (as in hitting keyboard keys), which is a big
turn-off. But it's self-documenting, which saves some typing to.

Anyway, I'm not contesting that The Ruby Way works. But nobody showed
evidence that The Ruby Way With Optional Interface Checking doesn't work
better, though people tried based on flaws of other languages. Ruby is a
dynamic language, but that doesn't say much about its users. (This is not
an argument, it's applicable to anything, it's a punch line).

Peter