Feedback on Records in JavaFX
brian.goetz at oracle.com
Sun May 10 15:05:24 UTC 2020
> In the examples you had with abstract classes, did they mostly have fields, or no?
> No, point 3 is specifically "classes that behave like records, but they extend an abstract class that does not have any fields”.
I am interested to see more details on this. If they have no fields, then could these have been turned into interfaces with default methods?
> Also, did you consider the point I made about accessor names of boolean fields?
This is a special case of the more general “why didn’t you just adopt the getX() naming convention.”
The naming convention was one of the most controversial aspects of this project. To many, it was “just obvious” that we should have adopted the JavaBean naming convention, because so much code out there uses it.
This is one of those areas where the perspective of a language design, or of platform steward, may differ significantly from that of the programmer-on-the-street. To a programmer, it’s all “just Java” — the language, the core libraries, the JVM, and even frameworks like Spring. But a language has different constraints, and therefore may equilibrate to different conventions, than a library or even an entire ecosystem of libraries.
The JavaBean naming conventions are _just one possible convention_. This is the advantage libraries have over languages — that different libraries can pick different naming conventions, as the domain demands — libraries have the option to “have it both ways” in ways languages do not. To the extent that the language gets into mandated-member-generation at all, on the other hand, it only gets to pick one naming convention for all programs, for all times. And while I understand why so many Java developers would naturally assume that we’d pick the JavaBean conventions, burning that convention into the language would have been a mistake. The _only_ convention we could justify from a language perspective is to name the accessors the way we did (and then, only because Java made the choice, for better or worse, to have separate namespaces for fields and methods.)
(Those that think that getX() is a “standard” in the community have probably not noticed that new APIs added to the platform over the past 5 or so years have tended to drift towards the x() accessor convention rather than the getX() convention.)
So if we couldn’t bend for getX(), we certainly couldn’t bend for the exception to getX() — isX().
More information about the amber-dev