amber-dev Digest, Vol 94, Issue 15

[forax at univ-mlv.fr]

Mine are covariant, try to not box and works across API boundaries :) 
(and also are typed as Object so they require compiler support, which is ... missing) 

https://github.com/forax/tuple-factory/ 

Rémi 

PS: they should work well with Valhalla. 

> From: "Vikram Bakshi" <vab2048 at gmail.com>
> To: "amber-dev" <amber-dev at openjdk.org>, "Remi Forax" <forax at univ-mlv.fr>
> Sent: Tuesday, December 10, 2024 11:52:42 PM
> Subject: Re: amber-dev Digest, Vol 94, Issue 15

> Might be off-topic for the mailing list but I thought I would share since it is
> on topic for the thread.

> Remi - you might like my library: [ https://easytuples.github.io/easy-tuples/ |
> https://easytuples.github.io/easy-tuples/ ]

> It is intended to provide as close to "structural" tuples as I think are
> possible in Java right now.

> On a previous thread it was stated that the in-place destructuring will come
> (nominal de-structuring of course not structural) but is lower priority.
> See: [ https://mail.openjdk.org/pipermail/amber-dev/2024-December/009105.html |
> https://mail.openjdk.org/pipermail/amber-dev/2024-December/009105.html ]

> Your example:

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

> Could eventually become:

> _2<Integer, Integer> minmax(int a, int b) {
> return _2.of(Math.min(a,b), Math.max(a,b));
> }

> void main() {
> _2(var min, var max) pair = minmax(7,3);
> }

> (the _2 type is my 'structural' pair tuple in the library I mentioned above)

> Regards,
> Vikram

> On Tue, Dec 10, 2024 at 10:01 AM < [ mailto:amber-dev-request at openjdk.org |
> amber-dev-request at openjdk.org ] > wrote:

>> 2. Re: Constructing records through reflection and module
>> restrictions ( [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] )

>> Message: 2
>> Date: Tue, 10 Dec 2024 11:00:57 +0100 (CET)
>> From: [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ]
>> To: Ryan Leach < [ mailto:rleach at rleach.id.au | rleach at rleach.id.au ] >, Ethan
>> McCue < [ mailto:ethan at mccue.dev | ethan at mccue.dev ] >
>> Cc: amber-dev < [ mailto:amber-dev at openjdk.org | amber-dev at openjdk.org ] >
>> Subject: Re: Constructing records through reflection and module
>> restrictions
>> Message-ID:
>> < [ mailto:1055813512.18413861.1733824857389.JavaMail.zimbra at univ-eiffel.fr |
>> 1055813512.18413861.1733824857389.JavaMail.zimbra at univ-eiffel.fr ] >
>> Content-Type: text/plain; charset="utf-8"

>> > From: "Ethan McCue" < [ mailto:ethan at mccue.dev | 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" < [ mailto:rleach at rleach.id.au | 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: [ mailto:forax at univ-mlv.fr |
>> > forax at univ-mlv.fr ] |
>> > [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] ] > wrote:

>>>>> From: "Brian Goetz" < [ mailto: [ mailto:brian.goetz at oracle.com |
>>>>> brian.goetz at oracle.com ] | [ mailto:brian.goetz at oracle.com |
>> >>> brian.goetz at oracle.com ] ]

>>>>> To: "Florian Weimer" < [ mailto: [ mailto:fw at deneb.enyo.de | fw at deneb.enyo.de ]
>> >>> | [ mailto:fw at deneb.enyo.de | fw at deneb.enyo.de ] ] >
>>>>> Cc: "amber-dev" < [ mailto: [ mailto:amber-dev at openjdk.org |
>>>>> amber-dev at openjdk.org ] | [ 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.htm
>> |
>> https://mail.openjdk.org/pipermail/amber-dev/attachments/20241210/bf0ddbb3/attachment.htm
>> ] >

>> End of amber-dev Digest, Vol 94, Issue 15
>> *****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20241215/bd5c7d86/attachment.htm>