Records -- current status
daniel.smith at oracle.com
Thu Mar 29 18:29:26 UTC 2018
This reads harsher than I intended, due to me efforts to be brief. So let me elaborate a little:
> On Mar 28, 2018, at 5:47 PM, Dan Smith <daniel.smith at oracle.com> wrote:
>> On Mar 20, 2018, at 8:15 AM, Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>>> So add all this up and we have three kind of finalness for fields:
>>> - by default mutable, but you can change it
>>> - by default final, and you can't change it
>>> - (and now) by default final, but you can change it
>>> This seems like quite a bad situation to me.
>> I think what you are really saying here is: if you want immutable records, wait for value records, don't try to cram them in early? Then a record inherits the finality of the class kind that it is describing. And same with field accessibility.
> Value records don't support recursion, so are useless for many applications.
> The sweet spot for records is immutable fields of any type. If the way to express that is to repeat "final" a bunch of times in the declaration, we will have failed.
To define "failed" more clearly: sure people will still use Java, they'll happily use the feature, things will be fine. But we'll be asking every record user to pay a tax (a handful of of "final" keywords) to accommodate the few weirdos who want mutable records.
Underlying this is my expectation that most record declarations will be short (many one-liners), and most will not need mutable fields.
The "non-final" keyword is a reasonable way to solve this problem without asking everyone to pay a tax. But Kevin's critique is also reasonable.
> It's a fair point that we are comfortable with "implicitly always final", but "final by default" is a new thing. And if there's a way to describe record-like things that have mutable fields without a 'non-final' keyword, great. But I think we need to spell those things using something other than "record Foo(int x, int y)".
What else could we do? Don't take these random ideas too seriously, but: maybe the declaration is a "mutable record"? Or just a "class", with some other signal that many record-like features are relevant? Or maybe the mutable fields appear in a different context?
I feel like we could probably come up with something reasonable if we felt that final by default with a "non-final" opt-in is too confusing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the amber-spec-experts