From: James Britt <james.britt@...>
Date: 2007-11-16T15:01:35+09:00
Subject: Re: ruby wish-list

Suraj Kurapati wrote:
> James Britt wrote:
>> you'll get a return value than can be interpreted as true or false
>                                         ^^^^^^^^^^^
> 
> Bingo!  I don't want to restrict the return values of question-mark 
> methods to only true and false because I see nothing special about 
> 'true' and 'false'.  In my mind, they are just objects that just happen 
> to have some useful equivalents when evaluated in a boolean context. 
> And that's the key point here: context.
> 
> Who cares what the type/class of an object really is, so long as the 
> object can be *interpreted* in a meaningful way in the particular usage 
> context?  Sounds like the fundamental concept of duck typing to me. :-)

This is what I'm warning against:

# First release of some library API
def account?
   @account
end

# In some naive end-user's code:
@a.cancel if @a = foo.account?

# Later release of library API, after some internal changes
def account?
   parent_has_account_and_is_active?
end


Now, what happens to the end user's code?

'account?' is still meaningful as a true/false indicator method; code 
(mistakenly) relying on a more meaningful return object may get a 
surprise one day.

I'm arguing that methods that end in "?" should be designed and used as 
answers to true/false  or yes/no questions.  That they can return an 
arbitrary non-nil object to indicate 'true' is convenient, but I'm 
skeptical of the value of "?" methods being used as both boolean 
indicators *and* object accessors.

Its a matter of hiding implementation details, and self-documenting code.

Now, should one do this?

def account?
   @account ? true : false
end


Well, maybe; it might keep end-users from trying to be too clever.

But I don't think it should be baked into the language.


-- 
James Britt

"Programs must be written for people to read, and only incidentally
  for machines to execute."
   - H. Abelson and G. Sussman
   (in "The Structure and Interpretation of Computer Programs)