>>>(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
>>    
>>
>
>Yes
>
>  
>
>>! => self if modified, nil if unmodified
>>    
>>
>
>! => self always. Frinstance, why can't we have something like
>
>Module Modified
>  def modified?
>    true
>  end
>end
>
>Module UnModified
>  def modified?
>    false
>  end
>end
>
>def method!
>  if changed?
>    self.extend(Modified)
>  else
>    self.extend(UnModified)
>  end
>  self
>end
>
>  
>
>>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
>>    
>>
>
>adams.found_answer? #=> true, false
>adams.answer #=> 42, nil
>
>Far more readable, IMO - in fact, it was the unintutive reading of a.nonzero?
>that took me aback in the first place.
>
But why should ? methods be required to return solely true or false? 
Isn't it enought to require that they
return objects that evaluate to true or false appropriately?

I agree that it's all right to specify that ? methods shouldn't be 
required to return values other than true or
false, but I don't think the opposite is true.  What I'm saying is that 
the return values of ? methods should
only be used in boolean situations, but they shouldn't necessarily be 
required to be booleans.  Using the
return values as other than booleans would probably be considered 
unsupported, since any object that
evaluated equivalently could be used to replace the current return value 
and have the function act
equivalently for its intended purpose.

The only place you gain with having ? methods return solely true or 
false is when you're using irb, which
isn't exactly for polished applications (correct me if I'm wrong), or if 
you're doing "puts blah?" directly,
in which case you should really be outputting a more coherent 
error/diagnostic message anyway.

And if you go back to ruby and duck typing, if foo? returns something 
that evaluates to true/false, then
it shouldn't matter if it actually is true/false or not.

Cheers

- Dan