<div dir="auto"><br></div><div dir="auto"><blockquote class="gmail_quote" style="width:343px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-color:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)"><div dir="auto" style="border-color:rgb(0,0,0)"><font size="4" style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><font face="monospace" style="font-family:monospace;border-color:rgb(0,0,0);color:rgb(0,0,0)">The definition of the approximation ordering <= is part of the e-p pair, along with the two sets being related and the two mappings.</font></font></div></blockquote><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">This is a very non-standard definition of an e-p pair; are you able to show any other piece of literature that agrees with your definition? Traditionally, the definition of <= comes with the domain, which is often the interpretation of a syntactic type (Boolean, in my example). I conjecture your definition becomes essentially useless when you consider any program larger than (new R(a,b)).p1()</div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></div><blockquote class="gmail_quote" style="width:343px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-color:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)"><div dir="auto" style="border-color:rgb(0,0,0)"><font size="4" style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><font face="monospace" style="font-family:monospace;border-color:rgb(0,0,0);color:rgb(0,0,0)">In any case, we're getting pretty far afield and I'm still not getting any closer to seeing the point you're trying to make, other than "I don't like how you designed records, and I think my idea is better, and I want to argue about it."  Which is (a) not the charter of this list, (b) arguing about decisions that are already made, and (c) does not seem to be offering any new information about why your way is better that wasn't already in evidence when the feature was being designed.  So I think we're kind of off the road here.</font></font></div></blockquote><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">Ok, there are a few points I want to make:</div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><br></div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">1) you brought up e-p pairs as a justification for the design of records. I have tried to explain that this justification is flawed. Your definition is also, and I am being as generous as possible, very non-standard. I would caution against using your non-standard definition to justify the design of any new features, and instead urge you to consult with programming language theory experts.</div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">2) the Java definition of record is, at best, very unusual when compared to most outside work. It fails as a tool to represent “a simple aggregation of data”, which supposedly was the goal.</div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">3) to be specific about what I think the problem is: Java still has no effective/ergonomic way to express product types. Specifically, the laws that product types are expected to obey *do not* hold of records. And these laws are not just academic concerns, they affect real users’ ability to grok code. Conversely, the extra “flexibility” that Java records come with (overriding accessors, equals, and hashCode) can be achieved perfectly well with ordinary classes. The only gain is more succinct constructors, and we can discuss the possibility of short-form constructors independently of records. There is real value in knowing with certainty that equals() and “accessors” are *standard*, not overridden, just like there is real value in knowing that fields are final.</div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">4) it’s not too late. Unfortunately, Java has now reserved the keyword “record” for something bizarre and there is no going back on that, but supposedly the purpose of the Amber project is to incubate new features, and nothing prevents us from doing it again under a new name (or a refinement of the existing concept) except, I speculate, a reluctance to make progress “too quickly” (or rather, catching up to 1970s programming languages & theory “too quickly”) and a reluctance to admit mistakes so soon after the release of records.</div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">5) some things are not just matters of opinion from a single disgruntled user. e.g. The covariance of arrays was a mistake. Consider the possibility that records are similarly flawed in a way that is not yet well-known to the Java community.</div><div dir="auto" style="border-color:rgb(0,0,0);color:rgb(0,0,0)">6) Java is probably not going away any time soon and these choices are going to impact generations of users. Please be responsible stewards and be open to listening to and acting on criticism, particularly from experts outside your immediate community, and forget about the concept of “too late”. Perhaps it’s a matter of either designing proper product types now, or 15 years from now when the issue is finally well understood by the Java community, which would truly be “too late”.</div><blockquote class="gmail_quote" style="width:343px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-color:rgb(0,0,0) rgb(0,0,0) rgb(0,0,0) rgb(204,204,204);color:rgb(0,0,0)"><div dir="auto" style="border-color:rgb(0,0,0)"><font size="4" style="border-color:rgb(0,0,0);color:rgb(0,0,0)"><font face="monospace" style="font-family:monospace;border-color:rgb(0,0,0);color:rgb(0,0,0)"></font></font></div></blockquote></div>