From: Daniel Sheppard <daniels@...>
Date: 2005-11-17T09:48:18+09:00
Subject: Re: Object#to_b

The actual need for an Object#to_b is that there's no way to make your
own custom object that will behave in a false/nil manner.

I can't think of a usecase where I'd want to put extra information into
a nil/false object instead of using exceptions, but maybe one of those
people that keep asking about subclassing FalseClass and NilClass can
explain their use-cases.

Unless somebody can come up with a decent use-case, I'd say that we just
change the if evaluations to also allow subclasses of FalseClass and
NilClass (which will all be just singletons as they don't have new). Or
change if to look at nil? to determine whether it's true or not.



> -----Original Message-----
> From: Austin Ziegler [mailto:halostatue@gmail.com] 
> Sent: Thursday, 17 November 2005 8:50 AM
> To: ruby-talk ML
> Subject: Re: Object#to_b
> 
> On 11/16/05, Daniel Schierbeck <daniel.schierbeck@gmail.com> wrote:
> > Currently, as far as I know, `if' and `unless' merely check if an 
> > object is of either types NilClass or FalseClass. This seems to 
> > contradict the duck-typing paradigm. I propose that we implement a 
> > method Object#to_b that is called by `if' and `unless'. It 
> should return a boolean value.
> > That way, a developer can decide whether or not an object should 
> > evaluate to true or false.
> 
> > One problem I see with this proposal is that it seems like a lot of 
> > people check if a variable has been set by writing `if var 
> ...'. This 
> > change would require that people wrote `unless var.nil?', which I 
> > personally find more correct as well.
> 
> This would break a lot of my code, personally. I used to use 
> "unless var.nil?" but it is easier to say:
> 
>   if var and var.foo
> 
> than:
> 
>   if (not var.nil?) and var.foo
> 
> I'm not *quite* sure what the "unless" version of the test would be:
> 
>   unless var.nil? or var.foo.nil?
> 
> Not quite what I want. I think that #to_b would be 
> problematic, especially in the example that you gave, since 
> it's more expressive to
> say:
> 
>   if conn.open?
> 
> than:
> 
>   if conn
> 
> which implies you're checking to see if conn is really there.
> 
> -austin
> --
> Austin Ziegler * halostatue@gmail.com
>                * Alternate: austin@halostatue.ca
> 
> 
> 
#####################################################################################
This email has been scanned by MailMarshal, an email content filter.
#####################################################################################