blank? is the best name I’ve heard for this thus far. I still have mixed feelings about 0 being considered “blank”—although that is an issue with the name, not with the functionality.

This precise functionality is very, very needed.

I also like blank?.

I like the concept, but I’m iffy about the name. What about null? nothing? void? ziltch? vacuous?

Or, along the lines of ring thoery: annihilator? :)

Ok, just kidding, blank? is actually pretty good.

I think nada? covers all the bases, even 0.

How about

nix?

Actually, the one that makes the most sense to me is

none?

How about a Zen mu? for detecting when there’s no answer?

You monkeys. Give me back my chapstick.

Only zeroes are monkeyproof. monkeyproof?

There has been an initiative of to_b. I pretty much liked that because its succint, mixes nicely with the existing to_* method army and deadly precise: what you want from the damned object is nothing else, just to spit out a Boolean value. No more hype please, come out and speak up which side you take! Pretty apocalyptic, eh?

But doesn’t isn’t 0.to_b dangerously close to the !0 debate? I think blank?’s main benefit is the fact that it sounds fuzzier. Does that make any sense?

What’s wrong with .blank? ? Love it.

I am blank.

So am I!

Me too!

I’m completely blank.

I’m with Bruce. I don’t really want to see methods that switch the polarity of 0 or "".

I just want every class to have a test for their most nominal value.

I’m not blank, honest! (heh heh heh)

False, I know you’re lying, as usual. The rest of you kids, pipe down and listen to Mister Why.

So let’s see, who do we have?

0
0.0
"" 
[]
{}
false
</p>

Am I forgetting anybody?  Hands up if I forgot to count you.

Oh yeah, "nil".  Well, I suppose it's no surprise you didn't pipe up.

Did I leave anybody else out?

Hmm, that SetOfBlankThings shoudl really hit the Preview button before posting. ahem

Anyhow. I like it. I think there’s a need for, as _why calls it, the “most nominal value”. I know it’s context-dependent. Sometimes zero is meaningful. Sometimes an empty string is a response. There are just enough cases where 0, nil, and an empty string are all “no response” or “not applicable”. It would be nice to have a test that everything responds to that catches this case.

As for to_b, I’ve never understood why that doesn’t exist. It would be different if the language didn’t depend on boolean values, but it does.

if [########]
  puts "It's true" 
else
  puts "It's false" 
end

Obviously, the language already has a “to_b” conversion it’s doing. Whatever is in that blanked-out area is evaluating to either true or false.

If false and nil returned false for to_b and everything else returned true, that would match what the language is doing internally.

I don’t see the downside to adding a to_b method to Object… on the other hand, at the moment I can’t remember when I needed it either. It juse seems to be missing.

http://dev.rubyonrails.org/ticket/783

What about Files, Dirs, and Ranges?

Blank for size 0
and
Blank for seek(0,IO::SEEK_END); pos 0

Sorry to rain on the parade, but I don’t like 0.blank? == true

As a CS guy, it just feels wrong to me to call 0 “blank”. I prefer the to_b approach: just like to_s asks for a string representation, to_b asks the object to represent itself as either true or false. Whether Fixnum chooses to return false for the valuation 0 is then a matter of convention, and not one of linguistics like with some of the other choices.

Gosh, maybe if we’d had a Boolean class we could have subclassed it years ago to solve our needs. But NOOOOOOOO , someone insists on being stubborn.

Well, it sounds like there’s two ideas here. One group wants to cast these values as false—which is reasonable, citing 0.to_a and other fuzzy conversions. The other clan wants a fuzzy conditional—reasonable considering the back history of question methods in Ruby.

It may be worthwhile to have both, but we clearly need at least one. This is a common snag.

I guess it boils down to: when a n00b on ruby-talk says, “Why does 0 evaluate to true in an if-statement?”—which of these alternatives are you most happy with presenting?

You’re thinking too locally, why. Imagine if we have a Boolean class. That class has two methods: true and false (which would be declared as global methods to keep the familiar syntax). Conditionals would then be based on how those methods are defined.

if venue['neighborhood'].to_s.empty?

if venue['neighborhood'].blank?

class Boolean
   def false
      nil or "" or 0
   end
end

# false if empty or 0
if venue['neighborhood'] 

The value of 0.blank? is totally dependent upon the application logic, just like your YAML invoice example shows. I don’t like this being in the Ruby language at all.

I’d like to see Ruby add true? and false? methods rather than a to_b method.

what about zero?

string.zero? (is it zero in length)

num.zero? (does it equal zero)

obj.zero? (does it reference address zero … do we have such an address in the heap…)

list.zero? (how many elements are there, zero? )

DO not consider it, it is just a joke!

BergerProposal++

People shouldn’t lambast the convention of 0 = false. It’s more than just a c compatability. Do a google for “Iverson Convention.” It’s common usage in math, and is particularly convenient in expressing summations dependant on some predicate:

x = Sigma_i[P(i)*F(i)]

The only contexts I can think of where zero should return true are probibly better expressed by explicit referenc to an exists? or defined? method.

Jason: Leaving aside my own views on it, I think it’s highly unlikely that “zero as true” is going to change. Too many people, not the least of whom is the language designer, like it that way. So it’s probably better to focus on something that has a chance of changing.

I particularly liked one of the messages in the “whoda thunk?” thread: ruby-talk:100810. The poster considers “zero as true” to be a “Licorice Test” for Ruby; either you love it or you hate it. I think this particular flavor is rather fundamental to Ruby being Ruby, it’s right up there with “Everything’s an object”

You could say: “All answers are true except the non-answer (nil), and true and false are their representatives.”

This proposal is now RCR 295. Let’s get a formal vote. Thanks for all your input. This has been totally productive.