Martin DeMello wrote:

>Dan Doel <djd15 / po.cwru.edu> wrote:
>  
>
>>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.  
>>    
>>
>
>But there's no way of enforcing the latter.
>
There's no static way of enforcing that ? methods can only return 
booleans, either, since variables
are untyped in ruby.  And since ? is just an extra symbol for including 
in method names, I don't
think the interpreter should fail, since someone could be strange an do 
something like
   
    obj.what_is_a?

Which is ugly to you and me, but someone else might like it, I suppose. 
:)  All I'm saying is that
in either case, it's merely a convention either way, and people may 
adhere to it or not.

>>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.
>>    
>>
>
>Yes, except that it's supported and used :) If it were a hack someone
>came up with I'd think it ugly, but be unbothered by it.
>  
>
Well, it shouldn't be used (probably).  Go back and read my final post 
on the duck typing thread;
I think it applies here. If a method's contract says, "returns a value 
that is true or false depending
on blah" then the contract only guarantees true or false, so nothing 
more can be used correctly.
If it says, "returns self when true, and nil when false," then those 
values can be used correctly. If
it says, "returns true when true, and false when false," then you're 
enforcing that programatically.

The ? doesn't define the contract, the person writing the method does.

>>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.
>>    
>>
>
>Yes if there's a specific documented and relied-on non-'true' true
>value. Not sure why I feel so prescriptive about this issue, but I find
>the whole thing very nonRubyish in the way it tries to pack two pieces
>of information into a single primitive value.
>  
>
I don't know that it's non-rubyish, but it is non-object oriented, in 
some sense. Or perhaps not
non-object oriented, but it flies in the face of some standard of 
"language purity."  But ruby
already does that anyway by treating nil and false as false, and 
everything else as true.

If the contract of ? methods is that they always return a true-value 
when the condition is true,
or a false-value when the condition is false, then it doesn't really 
make sense to return anything
other than true or false themselves (other than to save typing, because:

    def nil?
       self
    end

is shorter than

    def nil?
       self ? true : false;
    end

But that's not much of an argument).  However, that may not always be 
the explicit contract
of a ? method.  Perhaps the convention needs to be changed, or perhaps 
you need to re-
evaluate your concept of ? methods.  That's not really for me to say one 
way or the other.
However, I will say that if ? methods are meant to only be used as true 
or false values,
then it shouldn't matter whether the values returned actually are true 
or false (except in certain
circumstances where the fact that they aren't can be a real pain; see 
David's devil's advocate
post), and that concept is very rubyish.

- Dan