Martin DeMello wrote:
> Kent Dahl <kentda+news / stud.ntnu.no> wrote:
> 
>>Not yet on the duck typing train, I see.
>>
>>The ?-methods are still self-documenting in the sense that they tell you 
>>how you can use the result: as a boolean. That is a type, as in "I may 
>>be used in conditionals", and not a class, as quite evident by the lack 
>>of the Boolean common ancestor.
> 
> 
> Well and good, but they don't document the fact that the return value
> can be used as anything other than a boolean.

You're asking alot from a mere method name and a single character. For 
my special class, I might be able to use what I recieve from a to_s or 
to_str in a special way, and I'll have to document it. The important 
thing NOT to break, is how it works in the more general term.

Consider inheritance: You should comply with the interface of the 
superclass for substitutability. However, you may augment and extend it 
as long as it is still possible to substitute a parent object with a 
child object.

nonzero? just does this using core design decisions of Ruby (nil and 
false are only false values) instead of classes.

 > Duck typing or no, I find
> it conceptually messy to have a method called nonzero? return self
> rather than true - compare nil? and zero?. 

Well, we sure wouldn't want nil? returning self instead of true. Then it 
would only return nil or false. :-)

As for zero?, I guess it just wasn't useful enough to return self. Just 
what will you do with 0, 0.0, Rational(0,1) or any other zero that is 
returned? The nonzero? may return values from a much bigger set, and 
thus has lots of useful chaining possibilities.

> Using the value of self feels
> like relying on an undocumented side effect. 

Now I know Ruby is easy to read, but we can't have _all_ the 
documentation be Ruby source code. :-)
   http://www.rubycentral.com/book/ref_c_numeric.html#Numeric.nonzero_qm

> (I feel the same way about
> ! methods returning nil rather than self when they haven't made a
> change).

Are you saying the usage of ? and ! should be restricted to only the two 
protocols/types/interfaces? I.e.
? => result either true or false and
! => self if modified, nil if unmodified
That would be a huge blow against the readability potential of Ruby 
code, IMHO:

Real life:
- "Have you found the answer to life, the universe and everything?"
- "Yeah, it's 42."
Ruby code:
   adams.found_answer? #=> 42

-- 
(\[ Kent Dahl ]/)_    _~_    _____[ http://www.pvv.org/~kentda/ ]_____/~
  ))\_student_/((  \__d L b__/ (pre-) Master of Science in Technology  )
( \__\_/__/ ) _)Industrial economics and technological management(
  \____/_\____/ (____engineering.discipline_=_Computer::Technology___)