From: William Djaja Tjokroaminata <billtj@...>
Date: 2002-10-02T00:00:19+09:00
Subject: Re: thoughts on typelessness

Hi Dave,

I think in my application it is probably enough to check for classes.  For
example, my abstract factory pattern function to create a communications
network link is:

def link (node0, node1, rate = 1e6, delay = 0.0, model = nil, attrs = nil,
type = Link::TYPE_FULL_DUPLEX, label = '', name = '', simStart = false,
simEnd = false, sim = nil)
    raise "..." unless rate.kind_of? Float
    raise "..." unless delay.kind_of? Float
    ....
end

Really, I want the 'rate' and 'delay' to be of class Float and nothing
else.  There are so many input parameters, because to me they are all
essential in creating a link.  So when a researcher uses my code and
he/she just mistakenly skips one parameter, if the code omits some
confusing syntax error, the researcher may immediately think, "Oh,
what a buggy code".  But if the error message is something like "input
error in method 'link': 'rate' should be of type Float, method called
from line...", I think he/she will simply just immediately correct his/her
input.  (I know this does not handle all possible kinds of input errors,
such as negative number, but for now probably some checking is better than
no checking at all, because it at least helps me better.  When (and
if) the GUI is developed in the future, then it will be full-blown error
checking.)

Can you provide some idea on how to better deal with user input error
using probably some Ruby paradigm?

Regards,

Bill
============================================================================
Dave Thomas <Dave@pragmaticprogrammer.com> wrote:
> Ruby types are not releated to classes. They're related to object
> protocols (the infamous Duck Typing). That's what gives Ruby much of
> its appeal. Testing for classes is really very poor style, and
> artificially constrains the users of your code.