39 ms·

That is by design (https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html) Why not "just" do tuples?

That is by design (https://cr.openjdk.java.net/~briangoetz/amber/datum.html https://cr.openjdk.java.net/~briangoetz/amber/datum.html) Why not "just" do tuples? Some readers will surely be thinking at this point: if we "just" had tuples, we wouldn't need records. And while tuples might offer a lighter-weight means to express some aggregates, the result is often inferior aggregates. Classes and class members have meaningful names; tuples and tuple components do not. A central aspect of Java's philosophy is that names matter; a Person with properties firstName and lastName is clearer and safer than a tuple of String and String. Classes support state validation through their constructors; tuples do not. Some data aggregates (such as numeric ranges) have invariants that, if enforced by the constructor, can thereafter be relied upon; tuples do not offer this ability. Classes can have behavior that is derived from their state; co-locating state and derived behavior makes it more discoverable and easier to access. For all these reasons, we don't want to abandon classes for modeling data; we just want to make modeling data with classes simpler. The major pain of using named classes for aggregates is the overhead of declaring them; if we can reduce this sufficiently, the temptation to reach for more weakly typed mechanisms is greatly reduced. (A good starting point for thinking about records is that they are nominal tuples.)

hyperpallium 7y ago
> The major pain of using named classes for aggregates is the overhead of declaring them But the pain remains the same in client code. Because api's are written once, but used many times, it is more important to make client code simple than api code. In mathematics and programming, tuple content is accessed by position, not by name. e.g. The arguments in method/constructor invocation form a tuple - so there is precedent, even within java itself. Note that callers (clients) address arguments by position, and callees address them by name (api's). There'a a very similar passage in the article to the one you quoted. Regarding nominal vs structural there, a better example is that java's class system is nominal. "records" are nominal in that they have a class-like name, and also their content is accessed by name. Tuples are structural (not named), and access by position (not name). So I think records are not really "tuples".
- hyperpallium 7y ago
  EDIT as you can see, I'm concerned about the client experience for multiple return. Perhaps it's not so bad: 1. when assigning to a variable, type inference is easy, because can't subclass records, so can omit type ceremony. So, although nominal, client can treat as structural. 2. with standard IDE completion/lookup, user need't know or enter the exact accessor names. So, the assigned variable acts like a namespace. This mightn't be perfect, because appropriate names for the client's usage can differ from what is appropriate from the api's perspectice. (with tuples, user can name to suit their purpose).

hyperpallium 7y ago

> The major pain of using named classes for aggregates is the overhead of declaring them But the pain remains the same in client code. Because api's are written once, but used many times, it is more important to make client code simple than api code. In mathematics and programming, tuple content is accessed by position, not by name. e.g. The arguments in method/constructor invocation form a tuple - so there is precedent, even within java itself. Note that callers (clients) address arguments by position, and callees address them by name (api's). There'a a very similar passage in the article to the one you quoted. Regarding nominal vs structural there, a better example is that java's class system is nominal. "records" are nominal in that they have a class-like name, and also their content is accessed by name. Tuples are structural (not named), and access by position (not name). So I think records are not really "tuples".

hyperpallium 7y ago
EDIT as you can see, I'm concerned about the client experience for multiple return. Perhaps it's not so bad: 1. when assigning to a variable, type inference is easy, because can't subclass records, so can omit type ceremony. So, although nominal, client can treat as structural. 2. with standard IDE completion/lookup, user need't know or enter the exact accessor names. So, the assigned variable acts like a namespace. This mightn't be perfect, because appropriate names for the client's usage can differ from what is appropriate from the api's perspectice. (with tuples, user can name to suit their purpose).