Accessors

[Tagir Valeev]

I must say that I'm totally against introducing so-called properties
to Java records. So far, Java is a very clear language. If I see `x =
foo.bar`, I definitely know that it's a very simple field dereference
and assignment action. By no means, this line may perform a network
request or a database query. So when debugging, I don't expect
anything funny with this line of code. I don't need to navigate to
`foo` or `bar` definition to understand what's going on here. It's a
great feature, compared to other modern languages where many things
could be overridden and it's impossible to understand what's going on,
simply by looking at the code line. I don't want to lose this feature
in Java for the sake of saving two characters.

Also, as Brian mentioned already, there are separate namespaces for
variables and methods. Inside the record itself you can refer to raw
fields, rather than calling accessor. If we make accessor calls look
like field reads, there will be an ambiguity, at least within the
record itself. E.g. if you want to provide a defensive copy for outer
clients, it should not prevent other methods of records to access raw
fields, including raw fields of other instances of the same record
(could be useful in equals and compareTo). Kotlin has backing field
access (using the `field` identifier), but it could be used inside the
accessor only. And if you need to use a raw field outside of accessor,
you need to declare a backing property, which looks ugly. So it's not
that simple feature.

Finally, there's no point to make Java a second Kotlin, especially
given the fact that Kotlin already exists.

With best regards,
Tagir Valeev.


On Tue, Sep 22, 2020 at 8:34 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> 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.
>