Looking beyond records: better constructors (and deconstructors)

[Brian Goetz]

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.goetz at oracle.com 
> <mailto: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 
> <mailto:kevinb at google.com>