Forum: Ruby Object#to_b

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Daniel S. (Guest)
on 2005-11-16 23:37
(Received via mailing list)
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.

   class Connection
     def open?; end
     def closed?; end
     def to_b; open?; end
   end

   connection = Connection.new(...)
   if connection
     # ...
   end

Implementation:

   class Object
     def to_b
       true
     end
   end

   class FalseClass
     def to_b
       false
     end
   end

   class NilClass
     def to_b
       false
     end
   end


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.


Cheers,
Daniel
halostatue (Guest)
on 2005-11-16 23:53
(Received via mailing list)
On 11/16/05, Daniel S. <removed_email_address@domain.invalid> 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
eric.mahurin (Guest)
on 2005-11-16 23:56
(Received via mailing list)
On 11/16/05, Daniel S. <removed_email_address@domain.invalid> 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.

You could also ask that "and", "or", "not", "!", "||", "&&" be
operator methods.  I think the reason all of this is built-in is
performance.  All of this stuff doesn't have to go through the normal
method-call mechanism.  If you do a benchmark on "unless x" vs. "if
x.nil?" you'll see the difference.
vjoel (Guest)
on 2005-11-17 06:15
(Received via mailing list)
... or Object#not_to_b, that is the question.

I'm already sorry I said that ;)
Daniel S. (Guest)
on 2005-11-17 16:50
(Received via mailing list)
Joel VanderWerf wrote:
> .. or Object#not_to_b, that is the question.
>
> I'm already sorry I said that ;)
>

class Foo
   def to_b; end
   def bar
     if to_b or not to_b
       # ...
     end
   end
end

:)
Daniel S. (Guest)
on 2005-11-17 16:50
(Received via mailing list)
Austin Z. wrote:
> 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

`if var and var.foo' would still work. If `var' is undefined (nil), its
#to_b method will return false. So unless var is an object that
overrides the #to_b method, your code will still work.

I can see the problem with the performance Matz brought up, but this was
more meant as a philosophical discussion (though I can see now that I
was quite concrete.) It actually came in response to the whole
"subclassing FalseClass and NilClass" discussion, where I believe the
#to_b method would be more true to the idea of duck-typing.


Cheers,
Daniel
dooby (Guest)
on 2005-11-17 19:09
(Received via mailing list)
Joel VanderWerf wrote:
>
> .. or Object#not_to_b, that is the question.
>
> I'm already sorry I said that ;)
>

With good reason ;)

class Object; def to_b; !!self; end; end
alias that? to_b

that?  #-> true


daz
This topic is locked and can not be replied to.