Object#to_b

Currently, as far as I know, if' andunless’ 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' andunless’. 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 wroteunless var.nil?’, which I
personally find more correct as well.

Cheers,
Daniel

On 11/16/05, Daniel S. [email protected] 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.

On 11/16/05, Daniel S. [email protected] 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

Joel VanderWerf wrote:

… or Object#not_to_b, that is the question.

I’m already sorry I said that :wink:

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

:slight_smile:

… or Object#not_to_b, that is the question.

I’m already sorry I said that :wink:

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. Ifvar’ 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

Joel VanderWerf wrote:

… or Object#not_to_b, that is the question.

I’m already sorry I said that :wink:

With good reason :wink:

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

that? #-> true

daz