Feedback for records: Accessors name() vs. getName()

[Alex Buckley]

On 8/26/2020 5:13 AM, Roman Elizarov wrote:
> However, let us see what happens over time with the design of Java
> applications that use records. What if there is a business-domain need to
> extract a common interface between a TimeService and a TimeConfigSnapshot
> record since both of them essentially provide a pair of "currentTime" and
> "timeServerInfo"? Now, the understandable desire to avoid extra boilerplate
> would likely result in the introduction of the following kind of interface
> which is automatically implemented by the TimeConfigSnapshot record without
> additional code.

Since a TimeConfigSnapshot record is just a side-effect-free carrier for 
data, why should it get to drive the design of a broad API (TimeConfig) 
to which at least one pre-existing interface is expected to conform? 
That goes double when the pre-existing interface is not side-effect-free 
(synchronizeTimeWithServer). Why doesn't the pre-existing interface get 
to drive the design?

interface TimeConfig {
     Instant    getCurrentTime();
     ServerInfo getTimeServerInfo();
}

interface TimeService extends TimeConfig {
     Instant synchronizeTimeWithServer();
}

record TimeConfigSnapshot(Instant currentTime, ServerInfo
timeServerInfo) implements TimeConfig {
     public Instant    getCurrentTime()    {...}
     public ServerInfo getTimeServerInfo() {...}
}

The "extra boilerplate" of the delegation methods in the record class is 
unfortunate, but there is always going to be a mismatch somewhere when a 
side-effect-free API meets a side-effecting API. In fact, stepping back, 
this looks like a special case of the general wish that people have for 
a record class to offer getXXX methods in order to interoperate with 
pre-existing frameworks -- something I think Brian has already addressed.

Alex