I need to take back a few things that I said in my previous entry.  I
have been thinking a bit more about Groovy’s "." and "->" operators and I am
realizing that not only is my comparison with C/C++ and automatic unboxing
unfair, but that these operators can actually be quite useful.  Allow me to

The problem I have with the C/C++ version of these operators is that they
give you the illusion of choice.  The reality is different:  at any
time, there is only one operator that is valid, and using
the wrong one will result in a compilation error.  Therefore, I find it
stupid to put the burden of getting it right on the developer when the compiler
could infer the right operator itself.

Similarly, my comparison with auto unboxing is unfair in the sense that
automatic unboxing happens behind the scenes.  There is no obvious pointer
being dereferenced and receiving a NullPointerException will undoubtedly confuse
developers for quite a while.

Things are very different with Groovy’s operators and they are actually the
manifestation of a fundamental design decision when you write your code: 
is it okay to have a null pointer here or not?

In Java, you make this decision by using the code

String name = null;
if (null != customer) {
  name = customer.getName();


assert null != customer : "Customer shouldn’t null"
String name = customer.getName();

I don’t know about you, but I make these design decisions all the time in my
code, and nested null tests can indeed become very confusing and hard to read. 
And this is the part I was not getting:  Groovy’s operators are simply
syntactic sugar on top of a design decision.  You remain in control and
once you’ve made your choice, you are pretty much guaranteed to write your code
in the most concise way possible.

I guess it means I like it after all.