Feedback on records (JEP 359)

[Anthony Vanelverdinghe]

On 25/04/2020 20:42, Brian Goetz wrote:
> 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.
Thanks, this is exactly what I was missing!
>
> 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.
>
>
Thanks for elaborating, I totally agree now.

Kind regards, Anthony