Mike is at it again and this time, Groovy Properties are taking a beating…
I can only admire Mike’s thoroughness, he certainly researches his subjects
before posting about them, and everybody ends up more enlightened after reading
his posts. However, his conclusions are sometimes… questionable
🙂
First of all, I notice that of the twenty-one listings in his entry, only few
of them actually expose a flaw that deserves to be studied. More
precisely:
- Listings 1-6, 8, 10, 12, 13, 14, 15, 20, 21 are working as expected.
- Listings 7, 9 show bugs in the parser (which shouldn’t be newline-sensitive).
- Listings 16, 17 work as expected but admittedly with a gotcha (you need
to keep your types consistent, more on this below). - Listings 18, 19 show some behavior that will look odd unwil we come up
with clear specification of the unboxing behavior (not an easy topic, even
for JDK 1.5 which still hasn’t come out with a final word on it).
Listing 11 is the one that really got my attention, until I realized that the
rules to get it right are simple and they already exist: JavaBeans.
As long as you follow the JavaBeans rules, everything makes sense.
Anyway. I think we could dissect Mike’s examples one by one and argue
over them for days, but it’s way too early to do that. Instead, I’d like
to take a step back and discuss Groovy Properties in general.
At this early stage of Groovy’s existence, there are three possible scenarios
for Properties:
- Keep the current design and write a thorough specification to
disambiguate all the corner cases that Mike uncovered.I agree with Mike: Groovy Properties need to be improved, so I won’t
spend too much on this option.
- Modify the current design.
As part of the improvements, Mike and
Merrick suggested adding one ore more new keywords: "property", "rw",
etc… I have to say I find Mike’s fix quite curious, since he
complains about the magic of the current design (declaring a public field
will cause the generation of the proper accessors, which can then be used in
your code) and then proposes to fix it with a keyword "rw" which also
magically generates accessors (even worse: you are forced to use this
accessor to read or write the field!).
- Come up with a brand new design.
Since the JSR just started, I think we should explore this option seriously.
After reading Mike’s detailed analysis, I was struck by a very simple
realization: C# got it right.
The way C# implements properties addresses pretty much all the concerns that
Mike voices, including that of redundancy (if you spelled out the property once,
you shouldn’t have to declare it a second time), and arbitrary complexity
(declaring a simple property is very terse, but you can insert more logic in the
accessors at any time without breaking anything).
Whatever ends up in Groovy, I think the most crucial point is that of uniform
access. If my property is called "firstName", I should be able to refer to
it as "person.firstName". I don’t care if it’s going to be a direct field
access or if more complex logic is going to happen undercover.
After all, why would I care, as long as it returns the right value?