Feedback on records (JEP 359)

[Brian Goetz]

On 4/25/2020 2:05 PM, Anthony Vanelverdinghe wrote:
> Would you mind to clarify why the order [...] being semantically 
> significant is a problem? 

Because there are multiple consumers of this order, and they don't 
always want the same thing.

If I have

     record Name(String first, String last) { }

and I then want to add Comparable, but I want sorting (last, first), I'm 
already hosed, since changing the order of the components is not a 
compatible change.  And I am writing from scratch, I don't have this 
particular problem, but the natural order in which to declare the 
components when I think about the record may not be the natural ordering 
on which I want to sort.  So I would have two features that are 
_already_ fighting for control over the order.  (And, what if there were 
more order-dependent features?  This game doesn't even scale to two, let 
alone more.)

The main problem is that there is simply no reasonable way to infer a 
"right at least 99% of the time" sort order from the declaration of the 
components.  The sensible sort order may be any permutation of any 
subset of the components.  The feature, as you proposed, would be 
frustrating at least as often as it is satisfying.  (And while _you 
personally_ might believe you'll never ask for knobs, and might even be 
right, the probability that people will then come back and say "why 
can't I put an annotation on the component to indicate its role in the 
sort order" is 100%.  And now we're on the slippery slope back to 
Lombok-land.)

So basically, this is half a feature, for which we actively don't want 
to do the other half, which means we can't do the first half either.

> As I see it, the problem is that, for me, something like `record 
> TrackId(Year year, String albumTitle, int trackNumber)` just screams 
> at me: "hey, I'm Comparable, just as you'd expect me to be". And it 
> bothers me that I have to write the code nonetheless 

I get this; we'd all like to write less code (and we're getting there, 
bit by bit.)  But this is a "writing code" argument, not a "reading 
code" argument.  Reading code is more important than writing code.  If 
we were to infer a sort order, it would have to be the obvious one the 
overwhelming majority of the time.  And we're not even close to close on 
that.  So we have to say no to that, even though it might be helpful in 
some cases.