Getters vs. public final fields in records

[Andrew Cave]

> The definition of the approximation ordering <= is part of the e-p pair,
> along with the two sets being related and the two mappings.
>

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()

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.
>

Ok, there are a few points I want to make:

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.
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.
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.
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.
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.
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”.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220813/18a26f75/attachment-0001.htm>