3 ms·

There are things such as arrays that you cannot really make immutable as things are at the moment. So you will have to override the accessor and provide a copy

There are things such as arrays that you cannot really make immutable as things are at the moment. So you will have to override the accessor and provide a copy of the array. If the components were fields you would not be able to do this. Also if you are designing APIs for others to use. You might in some situations want to expose an interface instead of an actual record. As records are difficult to evolve. So having methods are much easier than fields in those situations. For example, the JDK itself mostly plans to use records behind interfaces.

doctor_eval 7y ago
It’s not clear that this is how records work though. I think only the top level fields are final - I don’t think there’s an expectation that the array contents would be immutable - and since you can’t redefine the methods, this would have to be done by the compiler and I don’t think that’s the case. Also, same problem happens with fields which are instances of classes; although the record is mutable, the instances are not. So I don’t think that’s the answer. I also don’t think records can implement interfaces.
- kasperni 7y ago
  Yes, you can override accessors and mutability is the main reason. It has been discussed a number of times on the various amber mailing lists, here is one [1]. Yes, records can implement interfaces. The syntax is {ClassModifier} record TypeIdentifier [TypeParameters] RecordHeader [SuperInterfaces] RecordBody [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001046.html https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...
  - doctor_eval 7y ago
    OK thanks. I misread an article as saying that records couldn’t be extended, but on rereading, it actually said that java.lang.Record couldn’t be extended other than by declaring a record. That makes a lot more sense, and certainly explains the use of methods instead of fields. Thanks! (I continue to dislike the syntax, FWIW)
pron 7y ago
Yes, deeper immutability and interfaces, but it also allows you use method references. Getting all the x components of a collection of Foo is just: foos.stream().map(Foo::x)

doctor_eval 7y ago

It’s not clear that this is how records work though. I think only the top level fields are final - I don’t think there’s an expectation that the array contents would be immutable - and since you can’t redefine the methods, this would have to be done by the compiler and I don’t think that’s the case. Also, same problem happens with fields which are instances of classes; although the record is mutable, the instances are not. So I don’t think that’s the answer. I also don’t think records can implement interfaces.

kasperni 7y ago
Yes, you can override accessors and mutability is the main reason. It has been discussed a number of times on the various amber mailing lists, here is one [1]. Yes, records can implement interfaces. The syntax is {ClassModifier} record TypeIdentifier [TypeParameters] RecordHeader [SuperInterfaces] RecordBody [1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2019-March/001046.html https://mail.openjdk.java.net/pipermail/amber-spec-experts/2...
- doctor_eval 7y ago
  OK thanks. I misread an article as saying that records couldn’t be extended, but on rereading, it actually said that java.lang.Record couldn’t be extended other than by declaring a record. That makes a lot more sense, and certainly explains the use of methods instead of fields. Thanks! (I continue to dislike the syntax, FWIW)

pron 7y ago

Yes, deeper immutability and interfaces, but it also allows you use method references. Getting all the x components of a collection of Foo is just: foos.stream().map(Foo::x)