And I agree with your dislike of the “->” proposal for much the same reason (hopefully the outcome of this should simplify things for programmers not introduce something new they have to think about – i.e. “do I use the dot or the arrow here let me think hmmm).

I guess the part I really wanted to comment on was that as I read your Field Access Example #2, I wondered if people would feel, as I do, that this has the static/dynamic language debate written all over it.

i.e. I don’t know java bytecode, but I’m guessing it’s safe to assume that as the java compiler creates the bytecode behind your two versions of the client code using the Payment class, the dollars field access bytecode will differ greatly from the setDollars method invocation call.

So in java the understanding of “.splat” is a compile time thing. For “.splat” to be an abstraction like you (and I) want, the java compilers would have to emit bytecode that try and understand what “splat” is *at runtime*, or else *calling* code is going to have to be recompiled whenever someone makes the kind of change you made to your Payment class in Example 2.

So in a way, given that Java in my mind is a statically typed, performance focused language in the vein of C++, I could almost forgive the idea that this should properly wind up in the Groovy and JRuby kind of languages, and not Java.

Because it seems a big change to think the compilers would be adding this kind of indirection for all the “.” references they find in the code, i.e. potentially a real performance drain given that the benefits might only apply in a small percentage of the time that “.” is used.