Looking beyond records: better constructors (and deconstructors)

[Kevin Bourrillion]

Sorry to have only a wishy-washy reply to offer.


On Fri, Jun 7, 2019 at 12:11 PM Brian Goetz <brian.goetz at oracle.com> wrote:

With most of the decisions regarding records being settled, let's take a
> few minutes to look down the road.  Records are great for where they
> apply, but there are plenty of classes that suffer from error-prone
> boilerplate that do not qualify to be records. We would like for some of
> the record goodies to filter down to ordinary classes, where possible.
>

FWIW, I am probably a lot less concerned about the "cliff" between records
and non-record classes than most. I suspect that most classes that have a
lot of record-like state but can't quite be records would probably be best
served by bundling up their record-like state into an actual record.


What we would need is to tell the compiler that the constructor argument
> "int low" and the field "int low" are describing the same thing.


I definitely recognize this problem in today's code; that adding a single
piece of state requires too many bits of code to be sprayed all over your
class. There is certainly appeal in the idea of being able to represent
that state as a single "thing" in the code, tying
constructor/deconstructor/getter/validation/etc. all together. You had a
past proposal that was trying to do something like that.  I did have some
reservations with that proposal, but now when I look at the current
proposal, it's aiming for so much *less* than that that it's not *clear* to
me it delivers enough benefit to bother with. You still have to spray
changes in almost as many places.

Even if this is one step that we intend to be followed by future steps, the
intermediate version would be used for some length of time and the set of
features it chose should feel like a worthwhile "sweet spot"... maybe this
clears that bar, but I'm not sure.


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190620/e5929528/attachment.html>