Fwd: Accessors

[Brian Goetz]

This was received on the amber-spec-comments list and am forwarding here to provide an answer.  

While not entirely clear in its terminology, the request seems to ask “why can’t we reinterpret field access against a record (r.x) as an invocation of its accessor.”  

First, this really has nothing to do with records; records are just classes.  Having special semantics for member access on records would not be a good idea; not only does that create a significant burden for users (having to remember what classes are records and what are not, so they can know what r.x means), but also, means that compatibly migrating between records and classes is made even harder since then the semantics of `r.x` would subtly change.  So while records might have seemed an attractive vehicle for changing something you didn’t like about Java, these are not the droids you are looking for.  

More generally, it is a very common temptation to try to use new features as vehicles to fix what we see as “mistakes of the past” (such as “let’s make the formal arguments of a lambda implicitly final.”)  This temptation is almost always counterproductive, because it creates new corners of the language that behave gratuitously differently, and leaves users to keep track of arcane rules based on what year a feature was added to the language.  (It was once seriously suggested that because records are new, we could allow semicolons to be optional in record bodies.  While I get that some people seem to think that semicolons are the worst thing about Java, this is an extraordinarily silly suggestion, because the resulting language becomes a hybrid frankenstein.)  While it may be locally satisfying to the faithful that at least some corner of the language “gets it right”, the resulting inconsistent whole is surely bad for the rest of the Java developers.  So let’s factor records out of this question.  

Essentially, what you’re really wishing for here is properties; the ability to “overload the dot” so that something that looks like a field access (x.f) is interpreted as a method invocation.  This is not a new idea, and in fact has been discussed to death; past iterations of the discussion resulted in long-spanning flame wars that I do not want to repeat or recount (or even recall!)  Suffice it to say that the previous thousand times this has come up, it was not seen as a sensible evolution path for the language, and I don’t see any reason it is different this time.  

I think describing having to type an extra “()” when accessing a component of a record as burdensome verbosity for clients is a bit of a stretch.  Java has separate namespaces for variables and methods for a reason; those () tell you a lot about what is going on in your program.  (If what you want is a class with public final fields, you can declare that too — that’s a different thing, but if that’s the semantics you want (which is not the same as a record!) you can do that too.)



> Begin forwarded message:
> 
> From: Buwanta Som <buwantasom at outlook.com>
> Subject: Accessors
> Date: September 20, 2020 at 9:35:24 AM EDT
> To: "amber-spec-comments at openjdk.java.net" <amber-spec-comments at openjdk.java.net>
> 
> Hello, I'd like to ask why Records are not used as a chance to remove the need of using accessor methods.
> As they are completely new, I believe they should use "accessor fields" or something like that when modification of the return value is needed, to remove the need for calling a method every time you need the value of a field. Personally, I use classes with public final fields for this purpose. It is cleaner and makes more sense.
> I want to know why there is no plan to invent fields as accessors specifically for Records, as they're not released yet.
> Once they are released Java will be locked basically forever to using accessor methods. Records are great for reducing verbosity when creating such classes but they don't do much to reduce verbosity of using them. If they are made this way then any future solution to the JavaBeans getter setter method problem will also only be useful for defining, not using and indirectly useful features such as += will be blocked for that kind of solution.
> 
> Sorry if this is the wrong place, I've never used mailing lists before.