Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I like how Groovy defines truth. Anything that is not one of these is true:

* 0

* null

* false

* empty String/collection

It may seem like too many rules, but it's very intuitive. For example, it's common in Java to do:

    if (str != null && str.length > 0)
Or:

    if (str != null && !str.isEmpty())
There's even a apache.commons helper function for that:

    if (!StringUtils.isNullOrEmpty(str))
While in Groovy that's just:

    if (str)
It's just handy. It also reminds me of Common Lisp, where `false` is defined to be the empty list itself! It just makes sense and in Common Lisp code the same idiom can thus be used, which makes it very easy to read and write.


The situation of multiple falsy values is more like Javascript than Common Lisp.

If you have only one false value, it means that this test

  if (str)
can mean "we have a string object here". If we make str take on the false value, such as nil, then that is not a string.

If an empty string is false, then we cannot use this test.

An empty string being false encourages the poor practice of using empty strings to mean "there is no value here".

You might as well code in Bash.


> An empty string being false encourages the poor practice of using empty strings to mean "there is no value here".

That is not bad practice, as I said before, you almost always want to only process non-empty Strings, but sometimes an empty String comes in from user input or whatever and you either have to check it everywhere like in Java, or in Groovy that is just the default... you can still do 'if (str != null)' to be more explicit, but in my experience that is almost never what you want. Bad practice is making the more usual case look more unusual.

Also, it's nothing like JS because in JS empty lists and maps are `true`! The commonality with Common Lisp is exactly that "not being empty" is what the concept of true represents.


This is so arbitrary. State what you want, make it explicit.

    if ( list_of_names ) { ... }
doesn't make any sense at all. For one thing, `list_of_names` should only be allowed to be `null` in exceptional cases; disallowing it removes a whole class of errors.

Second, imagine you have two handy operators / functions `not` and `is_empty`, then the above becomes either

    if ( not is_empty list_of_names ) { ... }
or

    if ( is_empty list_of_names ) { ... }
    
as the case may be. In which universe is that too long for a load-bearing program that people depend on?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: