Constructing records through reflection and module restrictions

[Remi Forax]

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Florian Weimer" <fw at deneb.enyo.de>
> Cc: "amber-dev" <amber-dev at openjdk.org>
> Sent: Sunday, December 8, 2024 4:50:43 PM
> Subject: Re: Constructing records through reflection and module restrictions

> Sure, there are other ways we could have designed the language. Tuples are
> structural types, which means they are not declared, but instead spring when
> the type constructor is applied to other (necessarily accessible) types. This
> means there is no need for access control, since anyone who can access T and U
> can "summon" the type `tuple<T,U>`. (We have this for arrays already -- which
> is already a significant source of irregularity in the language, so we chose
> not to emulate that.)

> But, we chose to lean into Java's class-based, nominal type system. Making
> special exceptions "because it's like a tuple" is surely convenience in some
> cases, but makes the language more complicated to reason about overall.
We have made an exception for lambdas. 

There is something special with tuples, most of my students now learn programming with Python as first langage, so there are used to use tuples as an element of design. 
As an example, when students start Java, we have a course to explain that Java has no tuples and the difference between a record and a tuple. 

Another example, currently, this is the time of the year where we are doing the advent of code, students can choose the langage they want, most of the undergraduate students choose Python. 
When asked why, having tuples is the most cited feature, and it makes sense given the kind of problems of the advent of code. 

I think we will have to fix this in Java at some point, not now, perhaps even not us, but exactly like we did not need lambdas because we had inner classes, not having tuples will be seen increasingly as a Java problem. 

regards, 
Rémi 

NB: For graduate students, most of them are using Java for the advent of code, but i suppose this is a kind of Stockholm syndrome reaction because they are using Java in most of their courses (concurrency, android, http server, design pattern, spring, etc). 

> On 12/8/2024 10:15 AM, Florian Weimer wrote:

>> It's the syntactic overhead.  The attractiveness of this pattern is
>> that's it's a clear and concise notation for this type of
>> deserialization.  Creating a public type for it in a suitable package
>> sort of breaks that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241208/f696953e/attachment.htm>