See, in #java all data types that aren't primitives inherit from the Object class. And that means that any process could generate an Object #array as its return value. It would be a single compound value, the elements of which can be accessed by index.
Up until #java11 however, if we were to access those elements, we were responsible for telling the compiler what #dataType we expected, and we would have to perform a type cast.
And the compiler couldn't check for type safety.
How different is this with a #programming #language like #Rust, which have tuples as a language construct:
With these languages the compiler does know what data types the tuple elements should be. They do not require us to program an additional type check or type cast.
The common solution in the #java #programming #language is not to return #tuples at all. Instead, we expect the programmer to create a custom data type which holds and can access a tuple's elements as strongly, statically typed class instance fields.
This is normal, for java.
It's also a lot of work.
It's verbose, repetitive, and each type requires a ton of testing, which is equally verbose and repetitive.
Time for java to embrace tuples!
@aeveltstra Verbose and repetitive, sounds like Java!
At least it's not as bad as writing GObject code in C.
@phoe Awesome! And sad at the same time. I've come across several differing tuple implementations. Including one I made myself due to specific needs.
Instead of everyone being forced to choose or create their own tuple mechanism, the programming language should implement tuple return values as a language feature.
@aeveltstra Throw the idea at the Java group.
@phoe I'll get there one day, if I feel like spending an inordinate amount of time on this language!
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!