Java gets tuples
For those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
Quote from Dave Voorhis on February 1, 2020, 12:05 pmFor those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
But it 's the human who still has to declare them ? So the language still doesn't get to have TTM's type generator concept ?
Quote from Erwin on February 1, 2020, 12:22 pmQuote from Dave Voorhis on February 1, 2020, 12:05 pmFor those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
But it 's the human who still has to declare them ? So the language still doesn't get to have TTM's type generator concept ?
No, but give it twenty or thirty years, and maybe we will.
Quote from Dave Voorhis on February 1, 2020, 3:33 pmQuote from Erwin on February 1, 2020, 12:22 pmQuote from Dave Voorhis on February 1, 2020, 12:05 pmFor those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
But it 's the human who still has to declare them ? So the language still doesn't get to have TTM's type generator concept ?
No, but give it twenty or thirty years, and maybe we will.
I don't have that many years left.
Quote from Dave Voorhis on February 1, 2020, 12:05 pmFor those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
This is a good thing. It's good to see a language evolving. Java got stuck for a while back there, but (like streams) this is definitely a good thing.
Yes, it has to be nominal. This is all done at the compiler level AFAICT, so it's all just syntactic sugar. You could have written this code, but it's nicer if you don't have to.
I still think it would be nice to have the value types and generics of C#, but that would be a discontinuity at least as bad as Python 3.0, so I'm not holding my breath.
Quote from Erwin on February 1, 2020, 7:19 pmQuote from Dave Voorhis on February 1, 2020, 3:33 pmQuote from Erwin on February 1, 2020, 12:22 pmQuote from Dave Voorhis on February 1, 2020, 12:05 pmFor those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
But it 's the human who still has to declare them ? So the language still doesn't get to have TTM's type generator concept ?
No, but give it twenty or thirty years, and maybe we will.
I don't have that many years left.
I might just make it, but it's unlikely.
Quote from dandl on February 1, 2020, 11:06 pmQuote from Dave Voorhis on February 1, 2020, 12:05 pmFor those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
This is a good thing. It's good to see a language evolving. Java got stuck for a while back there, but (like streams) this is definitely a good thing.
Yes, feature constipation has dislodged, which is excellent.
Though some would say it might have gone a tad far in the opposite direction. I've seen one case where a product development team adopted Java 13 one week and had to revert back to Java 11 (the newest Long Term Support release) a week later when a member of the team realised that the proposed product ship date was after the end-of-life date of Java 13.
Yes, it has to be nominal. This is all done at the compiler level AFAICT, so it's all just syntactic sugar. You could have written this code, but it's nicer if you don't have to.
Yes, the new record feature is essentially putting into the language what you previously did manually (and tediously), or did with a (typically annotation-driven) library like Lombok.
[Deleted]
Quote from Dave Voorhis on February 1, 2020, 12:05 pmFor those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
Thanks Dave, hmm now I'm confused.
This seems (on a quick scan) very comparable to what's been in Haskell for a long time. Yes Haskell records have nominal not structural typing. (To be precise, bits like the compiler auto-generating the hashCode() has been in place less than 10 years, but value-equals(), toString() equivalents date back to Haskell 1998. And Haskell has always had pattern matching on records. Of course Haskell records are not pointers to updatable structures: you 'update' by creating a new record with some fields copiied-forward.
I'm confused because the constant complaint is that Haskell's functionality is embarrassingly poor compared to other languages. And there's a design process been going on for several months trying to improve it, but failing to get much agreement (which has been the problem all along; there's no lack of 'just make it like C++'/'no, make it like Idris/Scala/...'/'no that'll break a lot of code').
And in Haskell there's heaps of packages providing record-alikes via generics and/or macros/templating -- of course they're mutually incompatible, and incompatible with this latest proposal.
So this latest in Java is trying to compiler-generate what otherwise needs a load of boilerplate code. Aside from the volume of boilerplate, was anybody unhappy with using as-was Java records?
Quote from AntC on February 2, 2020, 12:25 pmQuote from Dave Voorhis on February 1, 2020, 12:05 pmFor those interested in Java development, see https://blogs.oracle.com/javamagazine/records-come-to-java
Notably, still nominal typing rather than structural, but this is unsurprising in the overall context of Java.
Thanks Dave, hmm now I'm confused.
This seems (on a quick scan) very comparable to what's been in Haskell for a long time. Yes Haskell records have nominal not structural typing. (To be precise, bits like the compiler auto-generating the
hashCode()has been in place less than 10 years, but value-equals(), toString()equivalents date back to Haskell 1998. And Haskell has always had pattern matching on records. Of course Haskell records are not pointers to updatable structures: you 'update' by creating a new record with some fields copiied-forward.I'm confused because the constant complaint is that Haskell's functionality is embarrassingly poor compared to other languages. And there's a design process been going on for several months trying to improve it, but failing to get much agreement (which has been the problem all along; there's no lack of 'just make it like C++'/'no, make it like Idris/Scala/...'/'no that'll break a lot of code').
And in Haskell there's heaps of packages providing record-alikes via generics and/or macros/templating -- of course they're mutually incompatible, and incompatible with this latest proposal.
So this latest in Java is trying to compiler-generate what otherwise needs a load of boilerplate code. Aside from the volume of boilerplate, was anybody unhappy with using as-was Java records?
In the Java world, there's always someone who's unhappy with everything, but there weren't Java records before. There were only -- and still are only -- classes. The new record is just a built-in mechanism for generating a class. It mainly looks like a built-in replacement for Lombok, which a popular third-party library for generating "record" classes.
Pretty much everyone in the Java world is ok with classes.
I presume those complaining that "Haskell's functionality is embarrassingly poor compared to other languages" don't mean Java, C#, or similar ilk when they're talking about "other languages."