From: Rich Kilmer <rich@...>
Date: 2002-10-02T01:02:28+09:00
Subject: RE: thoughts on typelessness

Not that this discussion is about refactoring...but...

You could restructure this a bit and use a Hash instead of all those
params.

Just having to know the order of so many params is a nightmare.

LINK_DEFAULTS = {:rate => 1e6,
                 :delay => 0.0,
                 :type => Link::TYPE_FULL_DUPLEX,
                 :label => '',
                 :name => '',
                 :simStart => false,
                 :simEnd => false
                }

def link(node0, node1, map={})
  LINK_DEFAULTS.each do |key, value| 
    map[key]=value unless map.has_key?(key)
    unless map[key].kind_of? value.class
      raise "Invalid parameter type #{key} must be a #{value.class}" 
    end
  end
  ...do whatever you want with values
end

usage:

link(n1, n2, :name=>'wiggy', :simEnd=>true)

Oh...and the unless map...thingy checks all the types based on the
defaults ;-)

Just my $.02,

-rich

> -----Original Message-----
> From: William Djaja Tjokroaminata [mailto:billtj@y.glue.umd.edu] 
> Sent: Tuesday, October 01, 2002 11:00 AM
> To: ruby-talk ML
> 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.
> 
> 
>