3 ms·
> 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 writte
by 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 agoEDIT 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).