I don't disagree with any of this; while the boilerplate of constructor
bodies is O(n), the coefficient is small, compared to other O(n)
boilerplates that shall remain nameless.
What motivates me to put this forward now is that, as we get ready to
support pattern declarations, most deconstruction patterns will have the
same error-prone O(n) boilerplate as constructors. So whatever you
think the benefit of this is, multiply by 2, for the constructor and the
deconstructor -- and so kills a whole category of boilerplate before it
is even born.
On 6/20/2019 4:18 PM, Kevin Bourrillion wrote:
Sorry to have only a wishy-washy reply to offer.
On Fri, Jun 7, 2019 at 12:11 PM Brian Goetz <brian.go...@oracle.com
<mailto:brian.go...@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. |kev...@google.com
<mailto:kev...@google.com>
