Booleans don't exist in Ruby (2022)
23 points by rebeca
23 points by rebeca
Matz and the Japanese core folks have been adamant about this for quite a long time. It is strange.
What is strange?
That TrueClass and FalseClass don't share an ancestor for convenience.
I think I understand the argument. They don’t share an ancestor because there’s nothing to share.
It’s a question of philosophy. Forget about the concept of boolean and null for a bit. They are the theoretical terms.
Ruby doesn’t have boolean or null, it has objects. Ruby has true, false, and nil. All three of these are implemented independently, all three are objects, and all three have the same purpose of identifying a state. Treating true and false as boolean is a fundamental misunderstanding of the language and how it is supposed to be used. (This also applies to having typed variables.)
C doesn’t have booleans either. It has zero or not zero. And I think the smallest amount of memory you can allocate is a byte.
And now we get back to the idea of boolean. C doesn’t tell you what you can do with bytes so you can ignore the philosophical distinction in the actual implementation of the language.
Ruby… not so much. You actually have to make a decision how to structure the language internals. The choice was to follow the principles of the language. And there are a lot of people who want Ruby to follow the principles of traditional computer science.
I think it would’ve been stupidly trivial to add boolean to the language decades ago. (And frankly they should have.) It’s probably too risky now.
This is a great post, but just one comment: please don't attribute any meaning to the values returned by object_id. It happens to return particular values for immediates (like nil, false, true, etc), but we treat it as a meaningless unique identifier.
I can't think of a use case for making Boolean exist in a language like ruby. Does anyone have one?
Take a look at the discussion on the ruby bug posted earlier. :)
I thought those examples were not very compelling.
Things like doing:
case x
when String then ...
...
when Boolean then ...
end
Seem a bit contrived TBH. First, because it's difficult to think of cases where you'd treat both true and false the same way. And if you're gonna distinguish between true and false, just have a when true and when false cases. And second, because that when Boolean could be written as when true, false if needed; there's not much to be gained from that common superclass.
But! The ruby bug discussion is old. Nowadays i would think the best rationale for a Boolean class would be using it for a type-checking system, which seem to be in vouge.
Yes if you have type checking it has value. But then you're not using ruby anymore
Ruby allows type checking, it’s still Ruby. You might want to decide what for control to present and a boolean corresponds to a checkbox. Yes, there are other ways, but it wasn’t hard for me to conjure one, there are surely more.
It’s not crucial for the language, and it’s fine. I can still think it’s a little strange, though. Many people bump into this as a surprise - the blog post’s popularity indicates it’s at least interesting.
Update to the blog info: In ruby 3.4.7 nil.object_id isn't 8, but 4.
➜ irb
3.4.7 :001 > nil.object_id
=> 4
I remember nil being 4 back in Ruby 1.9.
Thanks! I wasn't aware of when it changed. I just wen't to run the post code on irb and this came differently. I wonder what version of Ruby he is using!