Record copy()/with()

Record copy()/with()

Brian Goetz brian.goetz at oracle.com
Mon Jul 20 16:59:18 UTC 2020

> Hello, Sergei!
>> I see a number of problems with your proposed approach.
>> 1. Naming. Java never specified any kind of derived identifiers using
> prefixes/suffixes/etc. And, in my opinion, it's for good, because such
> things make the spec dirty.

Yes, this was one of the driving principles behind the record design.  
While `withX()` is a reasonable library convention (though note that 
JavaBeans suggests `isX()` if x is boolean), it is a terrible convention 
for a language to force on its users.  The compromise we ended up at is 
that we can get away with `x()` as a name for a read accessor, because 
fields and methods are in different namespaces and you really can't 
argue that if `x` is a good field name, it's a bad accessor name -- but 
this is as far as we can go with "picking a convention."

This is a digression from your point, but we can take this a little 
farther, if we want, by recognizing that a deconstruction pattern is 
really like a "multi-accessor", and we could, if we wanted, derive 
accessor methods `x()` and `y()` from a deconstruction pattern with 
bindings x and y.  There are a few challenges to clear out first, but it 
will be nice if we can say "you thought a record acquired accessors, but 
really what is happening is it acquires a canonical deconstruction 
pattern, and the accessors are derived from that." This is one possible 
component of the "push the record goodies down into all classes" program.

But, the problem of "withers" is an important one, not only for records, 
but for inline classes and for ordinary immutable class. Telling people 
"just declare more accessors" would feel a step in the wrong direction.  
Our C# friends, leaning on properties, are introducing a `with x { ... 
}` construct in C# 9, which is one way to get there, and which I'm 
investigating -- but again, there are some roadblocks to clear before we 
can get there.  Working on it.

More information about the amber-spec-experts mailing list