Mike describes his experience with
Groovy, and he makes a lot of good points. The comments that followed
brushed on some other aspects of Groovy, such as the operators "." and "->".
Mike’s understanding is:
Oh, and ‘.’ vs. ->: I believe ‘->’ guarantees that you don’t get nullpointer
references, so you can say foo.stuff()->bar.hincky()->bat.fly(), and if foo,
bar, or bat are null it’s a NOP.
which is also what I inferred from the documentation I read (which I can’t
find any more, go try to Google for something like "." or "->"…). This
is also my understanding, but this behavior scares me.
We were confronted to the same problem in JSR 201 when trying to define the
behavior of unboxing in the presence of a null pointer. The initial draft
specified that the default value for the unboxed type should be returned, but
after careful examination (read: dozens of emails), we decided that hiding
a NullPointerException was a far worse offense. We decided overwhelmingly in
favor of throwing a NullPointerException, a decision which even now is still
controversial with the community (to the extent that we might actually decide to
do away with automatic unboxing altogether).
Groovy’s "." and "->" operators suffer from the same problem. I really
can’t think of a compelling reason to have both, but maybe someone will prove me
As a side note, I do have some history with these two operators, and it dates
way back. When I received my first CS classes, I remember asking the
following question to my compilation teacher: "Why does the developer have
to remember which one of . or -> she should use? Can’t the compiler infer
it based on the type of the lvalue?". I don’t remember ever receiving a
satisfying answer to that question, even when C++ appeared and admittedly
muddied the water with its feature of operator overloading (note that you can
redefine "->" but not "."…).
In summary, here is what I’d like to see modified in Groovy:
- Get rid of ->, keep "." and throw an NPE if necessary
- Either require parentheses for method invocations or not, but don’t
I am not quite sure I care as much about semicolons (or lack thereof) as Mike
does, nor do I see a compelling reason to modify the way accessors are defined,
but I challenged him to come up with a proposal so let’s see what he has in mind.
Show us the money, Mike!