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.
method Object#to_b that is called by if' andunless’. It
This would break a lot of my code, personally. I used to use
unless var.nil? or var.foo.nil?
if conn
which implies you’re checking to see if conn is really there.
#####################################################################################
This email has been scanned by MailMarshal, an email content filter.
#####################################################################################
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.
In Active Record:
class Foo < ActiveRecord::Base
has_one :bar
end
I want a simple test for presence of bar, so return nil from
Foo#bar if there is no associated object:
if foo.bar
# …
end
I also want to treat Foo#bar as a reflection of the association
so I can have meta-methods for querying the column type, creating
objects, performing scoped queries, etc:
This usage feels very expressive and is possible for one-to-many
and many-to-many associations because acting like an Array is not
a problem. But for one-to-one associations, we must act like nil,
which is impossible due to RTEST doing direct object comparison.
to_b is one way to do it, but I think it is too disruptive.
I would prefer to define #nil? and have RTEST call it.
Best,
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
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 don’t know that this is a good or useful thing. I think that it would
decrease the overall clarity of Ruby code.
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.
And I think that if they do, they’ll be directed to different possible
solutions.
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.
Hm. No, I don’t think that either is good. I would suggest that neither
FalseClass nor NilClass should meaningfully have subclasses and that if
should not look at #nil?. I don’t think that there is a good case to
be found
for this at all.
I would not like new false values, but I would like to be able to
proxy the existing false values. Especially nil.
Ah, fudge. I hadn’t thought of that. That is one place where
lazy.rb falls down.
promise { false } will always be true
(unless you use an explicitly force()'d value.)
What is the cost [of allowing NilClass and FalseClass subclasses]?
I don’t see any way that it could be as efficient as the current
setup, where nil and false are immediate values and are checked
with a simple bitmask.
I don’t see any way that it could be as efficient as the current
setup, where nil and false are immediate values and are checked
with a simple bitmask.
Could they get special object_id’s that are easy to check?
I don’t see any way that it could be as efficient as the
current
setup, where nil and false are immediate values and are checked
with a simple bitmask.
Could they get special object_id’s that are easy to check?
That means we get 24 bits worth of symbols, 31 (signed) bits of
fixnums, and 31-bit pointers to objects (so objects must be aligned
on two-byte boundaries).
Right: I had to dig as far as RTEST when I tried to act like nil
to understand why it did not work. I was happy to see that it’s
very fast but was unhappy to discover the “line in the sand” between
dynamic, expressive Ruby and its concern for raw performance.
I think one of the interesting/useful features of Ruby is its
handling of boolean values. In thinking about the original post,
I came across a nice discussion of nil, null, and false in object
oriented languages, in particular Smalltalk and Objective-C.
I really like the null object pattern but I’m not sure I’m ready
to fully embrace it with a generalized null object and even then I’m
not sure how I think that should fit with nil/false.
My hunch is that either you have a generalized null object that is
considered false or you don’t have it. The idea of having user-defined
false objects just seems to be a opening a Pandora’s box of issues.
What is the cost [of allowing NilClass and FalseClass subclasses]?
I don’t see any way that it could be as efficient as the current
setup, where nil and false are immediate values and are checked
with a simple bitmask.
Right: I had to dig as far as RTEST when I tried to act like nil
to understand why it did not work. I was happy to see that it’s
very fast but was unhappy to discover the “line in the sand” between
dynamic, expressive Ruby and its concern for raw performance.
There is a Moore’s law for one but not the other.
Has anyone measured the cost of doing boolean tests the Ruby way?
Clearly it will be much slower as a microbenchmark, but perhaps the
overall cost for most Ruby programs is low enough to tip the balance.
And if not now, perhaps in one year.
jeremy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (Darwin)
