----- Mail original ----- > De: "Guy Steele" <guy.ste...@oracle.com> > À: "Brian Goetz" <brian.go...@oracle.com> > Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net> > Envoyé: Jeudi 29 Mars 2018 21:25:56 > Objet: Re: Records -- current status
> I've always assumed that, eventually, if we wanted too, we could always spell > it > as > > !final > > That also makes possible such explicit declarations as !volatile and > !transient > . . . And possibly even !null. > > !final !null String x = "quux"; // mutable, but you can't set it to null > > —Guy !final is a property of the variable while !null is more a property of the type. I see no problem to have a keyword 'mut' like in Rust instead of !final. But before i think we need to have a way to reverse the defaults or at least spell them by example at module declaration. default field final, parameter final, variable mut; default ref nonnull; Rémi > > Sent from my iPhone > >> On Mar 29, 2018, at 2:39 PM, Brian Goetz <brian.go...@oracle.com> wrote: >> >> >>> 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 something else.)
