Constructing records through reflection and module restrictions

[forax at univ-mlv.fr]

> From: "Ethan McCue" <ethan at mccue.dev>

> I'd wager the feature being missed in those cases is in-place destructing, less
> so anonymous components.

> From: "Ryan Leach" <rleach at rleach.id.au>

> The way I've seen records adopted and used, seem pretty far removed from Tuples,
> so don't really understand why you are in support of making them more
> Tuple-like Remi. I suspect we'll see true Tuples being introduced long before
> records are considered to be turned into Tuples. Not that I suspect that's
> particularly likely.

yes, i'm not arguying that records should be tuples, only that for a lot of my students, they see tuples are a building block and Java is missing that. 

As Ethan said, in-place structuring/destructing is another name for tuples (with named components). 

By examples: 
(int min, int max) minmax(int a, int b) { 
return (Math.min(a, b), Math.max(a, b)); 
} 

void main() { 
var (min, max) = minmax(7, 3); 
// or 
var result = minmax(...(7, 3)); // with a spread operator 
} 

As Brian said, the main issue here is that those things are structural typed, not nominally typed. 

Rémi 

> On Mon, 9 Dec 2024, 3:07 am Remi Forax, < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>>> From: "Brian Goetz" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ]
>>> >
>>> To: "Florian Weimer" < [ mailto:fw at deneb.enyo.de | fw at deneb.enyo.de ] >
>>> Cc: "amber-dev" < [ mailto:amber-dev at openjdk.org | 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/20241210/bf0ddbb3/attachment-0001.htm>