amber-dev Digest, Vol 94, Issue 15

[Vikram Bakshi]

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/

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

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 <amber-dev-request at openjdk.org> wrote:

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