Records -- current status
brian.goetz at oracle.com
Thu Mar 29 18:39:09 UTC 2018
> 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.
I'm OK with finding other ways to do this than "non-final", though I
think its quite likely that the "non-*" convention will muscle its way
in at some point anyway (to name one example, classes that would be
sealed by default will need a way to say "not sealed"), so I don't want
to put too much stock in keyword-sticker-shock-avoidance. (I actually
think non-final is a pretty good answer here; no one will be confused
the first time they see it (they'll just bikeshed that it should have
been spelled μtable" or something like that.))
I'm less OK with saying "let's do immutable records now, and then figure
out the mutability story."
While some of the goodies for records will eventually filter down in
some form to classes (e.g., better ways to fill in the obvious defaults
in constructors, better ways to declare equals/hashCode), I also don't
really want to count on that; I'd like to do a complete record feature
and then select the bits we want to transplant to classes.
I guess the question that this particular sub-thread is looking for an
answer to is, which we dislike less: having to say final a lot, or
having a new and different default for mutability of record fields. (Or
More information about the amber-spec-observers