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

  • 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:

  1. 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.

  2. Modify the current design.

    As part of the improvements, Mike and

    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!).

  3. 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?