nil.blank?
C2 Wiki discusses how nil.to_s.empty? is available in rails and nil.blank? is provided for Ruby On Rails,
Ruby
[source:ruby]
nil.to_s.empty?
>> true
[/source]
Rails
[source:ruby]
nil.blank?
>> true
[/source]
Java
[source:Java]
String s = null;
return s == null;
>> true
[/source]
Let’s say we want to check that s is non-blank string. The danger is that s could be null. We will use random to seed s (Or just think of it as the invisible hand typing a form value). In ruby we can do:
[source:ruby]
s = rand < 0.5 ? “” : nil
!s.blank?
>> true
[/source]
And in java?
[source:Java]
String s = Math.random() < 0.5? “” : null;
return !s.equals(“”); //Playing roulette
>> NullPointerException?!
if (s!=null) {
return !s.equals(“”);
} else {
return false;
}
>> true
[/source]
Verbosity, or simplicity? I feel that in web development where checking for blanks occur on a frequent basis, ruby has the better syntax. Not just in length, but it fits with my mental context as well.
September 28th, 2007 at 5:43 pm
You are mistaken in the roulette statement regarding Java – the solution is to simply reverse the equals statement. You therefore should show:
final String s = Math.random()
September 28th, 2007 at 5:46 pm
Good to see my whole post come through there 🙂
To clarify (and hopefully this one shows):
You are mistaken in the roulette statement regarding Java – the solution is to simply reverse the equals statement. You therefore should show:
Granted, it is not as clean as the ruby example, but to claim that the alternative is the best that Java can do is incorrect.
September 28th, 2007 at 6:33 pm
@Jonathan: You are most certainly correct. I have done that myself too (should have remembered 😉 ) It is a testament to programming languages that anything is (almost) possible. However, the question of how the language construct will fit with your expectations will arise.
The example I gave is clearer for a Java developer (That’s how I would have coded), and with an IDE, I will just crank that out quickly with curly brackets and all. The problem arises (sometimes) when I look back at the code, and find it hard to navigate. Hence the comparison.
September 28th, 2007 at 7:16 pm
So your defence is that by writing crappy Java code you’re going to struggle later on to understand it? I don’t think Ruby will solve this problem for you. This is universal, and should be mitigated by good variable names, documentation where documentation is necessary, and most importantly, not caring about succinctness.
My point is, I get the feeling that sometimes Ruby programmers try to fit too much on a line. Java can do the same, but it’s less prevalent. My case in point, lets rewrite your ‘bad’ Java example in what I would deem ‘Ruby-esque’:
I think you’d agree that is no better than the ‘proper’ answer that I provided, but it’s a hell of a lot tougher to understand.
So, to close – what exactly is ‘wrong’ with the ‘bad’ Java example you pose – it’s instantly readable. My personal opinion on much Ruby code is that it isn’t always immediately readable like this, but that it is (in the worst case) just as decipherable as my Java example above.
September 29th, 2007 at 1:06 pm
[…] a teeny bit of a discussion on another blog last night, and I think I should provide a bit more of a discussion on it here. Basically, the premise of the […]
September 29th, 2007 at 5:25 pm
Obligatory pythoners view… 🙂
In Python, “” and None both evaluate to false in a boolean comparison… this makes things quite simple in most cases (and you can always check more explicitly for None with
s is None)# Explicit casting to booleans...
bool('')
>> False
bool(None)
>> False
bool('banana')
>> True
October 2nd, 2007 at 1:31 pm
@Jonathan: To explain further about “how the language construct will fit with your expectations “, I personally don’t think that “”.equals(s) is a good idea, as “”.equals(s) is the opposite intent of what I set out to accomplish, which is s.equals(“”).
As with the example that I posed, it is not good because I do not care if s is null. Looking back at the code, I will wonder what was I trying to do
here? Was I looking for nulls as well? Why should I?
As you stated s == null ? false: !s.equals(“”) is no better and I agree. That was the point of the post, s.blank? ( and “”.equals(s) ) is more understandable.
@Rob: thanks for the pov of python. It is interesting how casting is used is determine truth. Is that a standard way in Python? just curious.
October 9th, 2007 at 2:21 pm
Just thinking about the common case, web forms, and Python, something I do frequently is take advantage of Python’s idiom for dealing with dictionary keys that may or may not exist.
>>> form = {} #empty dictionary
>>> form[‘name’] #blows up because there’s no key ‘name’
Traceback (most recent call last):
File “”, line 1, in
KeyError: ‘name’
>>> form.get(‘name’) # returns None
>>> form.get(‘name’, ‘anonymous’) # returns specified default value
‘anonymous’
>>> form.setdefault(‘name’, ‘bozo the clown’) # returns default value AND creates new entry
‘bozo the clown’
>>> form
{‘name’: ‘bozo the clown’}
>>>