From: Bulat Ziganshin <bulatz@...>
Date: 2002-10-02T14:57:37+09:00
Subject: Re: thoughts on typelessness

Hello William,

Tuesday, October 01, 2002, 7:00:19 PM, you wrote:

1) i think that

class PositiveFloat < Float
  def init
    super
    raise "..." unless self>0
  end
end

will be better

2) how about ``keyword arguments''? from "programming ruby" book:

Collecting Hash Arguments

Some languages feature ``keyword arguments''---that is, instead of passing arguments in a given order and quantity, you pass the name of the argument with its value, in any order. Ruby 1.6 does not have keyword arguments (although they are scheduled to be implemented in Ruby 1.8). 

In the meantime, people are using hashes as a way of achieving the same effect. For example, we might consider adding a more powerful named-search facility to our SongList. 

class SongList
  def createSearch(name, params)
    # ...
  end
end
aList.createSearch("short jazz songs", {
                   'genre'            => "jazz",
                   'durationLessThan' => 270
                   } )

 


The first parameter is the search name, and the second is a hash literal containing search parameters. The use of a hash means that we can simulate keywords: look for songs with a genre of ``jazz'' and a duration less than 4 1/2 minutes. However, this approach is slightly clunky, and that set of braces could easily be mistaken for a block associated with the method. So, Ruby has a short cut. You can place key => value pairs in an argument list, as long as they follow any normal arguments and precede any array and block arguments. All these pairs will be collected into a single hash and passed as one argument to the method. No braces are needed. 

aList.createSearch("short jazz songs",
                   'genre'            => "jazz",
                   'durationLessThan' => 270
                   )




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

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

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


-- 
Best regards,
 Bulat                            mailto:bulatz@integ.ru