Static Tuples in java ?

[esam kan]

coming from C#.NET where i am able make a method like this:

Tuple<string,int,int,bool> MyMethod(string name ,int accessLevel)
{

    //do stuff
}

Tuple<string,int,int,bool> is static and i can alter the <string,int,int,bool> as much as i wish. the primary advantage of this is avoiding making too many value objects (with complex programs value objects could grow out of control).

what is the equivalent in java ? because i searched i couldn't find any.

[Stephan van Hulst]

Java doesn't have an equivalent. The idea is that a tuple is a data construct that doesn't convey *what* it is that a method returns. There's nothing wrong in defining a simple struct-like class that returns your data in a semantic way.

ResultOfDivision divide(int dividend, int divisor) {
  int quotient = dividend / divisor;
  int remainder = dividend % divisor;

  return new ResultOfDivision(quotient, remainder);
}


static final class ResultOfDivision {

  final int quotient, remainder;

  ResultOfDivision(int quotient, int remainder) {
    if (remainder < 0)
      throw new IllegalArgumentException("Negative remainder");

    this.quotient = quotient;'
    this.remainder = remainder;
  }
}

[esam kan]

thank you.

Stephan van Hulst wrote:Java doesn't have an equivalent. The idea is that a tuple is a data construct that doesn't convey *what* it is that a method returns.

i would say comments to the rescue here. i write a lot of comments . my code is so clear to anyone reading it. i actually over explain things in my comments , you feel like reading a tutorial .


yes for sure ,nothing >wrong< with defining a value object , i agree. but if you have so many value objects in you program you will start pulling hairs before you become old. especially if you need to modify those methods later on. plus giving the option to programmers is always good (at least the one's who are full of wisdom).

java is so old now and still they don't have those i feel like omg!!

[Tim Harris]

esam kan wrote:...plus giving the option to programmers is always good (at least the one's who are full of wisdom).

Those exist?!?!?! *wink*

[Jesper de Jong]

If you really want this, you can easily create your own class Tuple with generics.

But Stephan is right: it is better to define a value class, because that will make it much more clear what each of the values in the class mean. If I look at the declaration of your method, and I see its return type Tuple<string, int, int, bool> then I have no idea what the four components in the Tuple are. With a value class, it's immediately clear what each of the components means.

[esam kan]

Jesper de Jong wrote:If you really want this, you can easily create your own class Tuple with generics.

But Stephan is right: it is better to define a value class, because that will make it much more clear what each of the values in the class mean. If I look at the declaration of your method, and I see its return type Tuple<string, int, int, bool> then I have no idea what the four components in the Tuple are. With a value class, it's immediately clear what each of the components means.

that is a reason why comments exist.

so you want a program to contain god knows how many value objects and how much complexity it add to the maintenance of the program ,just to save a line of comment explaining the return value ?

[Mike. J. Thompson]

Tuples don't make much sense in java firstly because java is statically typed and secondly because java does not have a rich enough syntax to allow you to unpack the tuple directly into variables.

Static typing in java means that the general idiom for communicating information about returns from methods is through the type name, which hopefully conveys some domain information if the names are good. This means that it is definitely a good idea to use value objects in Java.

The static typing also makes it impossible to have a generic tuple that can have an unlimited number of differently typed contents. I think C++ gets around this by having multiple tuple classes, each with one more templated parameter than the last, up to a 'reasonable' number.

Python both allows you to unpack tuples into variables and to have any number of different types in the tuple. You do require good documentation to know what is being returned, but this fits in with the general idiom for python and in my opinion works very well.

C++ has a rich enough syntax that a technique was found to allow you to unpack tuples directly into variables. it is a little more unwieldy than python, and consequently a little harder to read. It's ok now and then, but probably not something to use all of the time.

If tuples were used extensively in Java I think they would have all of the downsides of tuples with none of the benefits, would make code less readable, and would be non-idiomatic.

[Stephan van Hulst]

esam kan wrote:that is a reason why comments exist.

so you want a program to contain god knows how many value objects and how much complexity it add to the maintenance of the program ,just to save a line of comment explaining the return value ?

I'm not a fan of comments. If I can write code that is clear without any line of comment, I'm happy. If I have to write a line to explain what I'm doing, I try to refactor.

I think that if a lot of your methods need to return more than one thing, you probably need to redesign your API anyway. I almost never feel I need to return a tuple; only sometimes in complex recursive functions.

[esam kan]

Mike. J. Thompson wrote:Tuples don't make much sense in java firstly because java is statically typed and secondly because java does not have a rich enough syntax to allow you to unpack the tuple directly into variables.

Static typing in java means that the general idiom for communicating information about returns from methods is through the type name, which hopefully conveys some domain information if the names are good. This means that it is definitely a good idea to use value objects in Java.

The static typing also makes it impossible to have a generic tuple that can have an unlimited number of differently typed contents. I think C++ gets around this by having multiple tuple classes, each with one more templated parameter than the last, up to a 'reasonable' number.

Python both allows you to unpack tuples into variables and to have any number of different types in the tuple. You do require good documentation to know what is being returned, but this fits in with the general idiom for python and in my opinion works very well.

C++ has a rich enough syntax that a technique was found to allow you to unpack tuples directly into variables. it is a little more unwieldy than python, and consequently a little harder to read. It's ok now and then, but probably not something to use all of the time.

If tuples were used extensively in Java I think they would have all of the downsides of tuples with none of the benefits, would make code less readable, and would be non-idiomatic.

i think this is one example of people get used to things that have limitations. for example when we had CRT TVs back in the day we used to feel like 20 inch TV is so large. but now with 40 or even 50 inch TVs being cheap we started to look at the past and ROFL.
back to programming . if you ask me "without looking to the past can you tell me how a function / function call should looks like? " i would say :

a method

public (int empID ,string empName ,bool isActive) MyMethodName ( int userID ,string userName)
{
    // do stuff
    empID = 5;
    empName = "my text here";
    isActive =true;
    return;
}

a call to that method

    // a method call
    (int empID ,string empName ,bool isActive) MyMethodName ( 25 , "just a name");

any technical reason (not personal preference) why this can't work in any managed language ?

in c# they have "ref" and "out" keywords for example like this
public void MyMethodName ( int userID ,string userName, ref int empID , out string empName ,out bool isActive) { // do stuff empID = 5; empName = "my text here"; isActive =true; }

if you used the keyword "out" on an argument you HAVE to assign it a value before the end of the method otherwise the compiler will stop you. if you use the keyword "ref" you CAN assign it a value or ignore it. in either case when you call it you HAVE to include the "out" or "ref" with that variable in function call (for clarity) like this:

int empID; string empName; bool isActive; MyMethodName ( 15 ,"some name", ref empID , out empName ,out isActive);

[Junilu Lacar]

esam kan wrote:i would say comments to the rescue here. i write a lot of comments . my code is so clear to anyone reading it. i actually over explain things in my comments , you feel like reading a tutorial .

I would wager that hardly anyone reads your comments, especially the ones that read like a tutorial. Ain't nobody got time for that. Clear, self-documenting code is far better than comments. There are certainly some kinds of comments that are useful but I prefer reading clear code that reveals its intent over reading gratuitously commented code. Show me some "well-commented" code and I could probably show you an uncommented version of it that reads better.

[Mike. J. Thompson]

esam kan wrote:

i think this is one example of people get used to things that have limitations.

I'm not sure I understand your point, but I can only assume you misunderstood my post. I never said that Tuples are a bad thing (i use them all the time). What I did was list the reasons why I don't think they work very well in Java with its current syntax. Different languages have different strengths and weaknesses and it makes sense to use languages to their strengths and produce the most maintainable code possible.

[esam kan]

Mike. J. Thompson wrote:

esam kan wrote:

i think this is one example of people get used to things that have limitations.

I'm not sure I understand your point, but I can only assume you misunderstood my post. I never said that Tuples are a bad thing (i use them all the time). What I did was list the reasons why I don't think they work very well in Java with its current syntax. Different languages have different strengths and weaknesses and it makes sense to use languages to their strengths and produce the most maintainable code possible.

i would say thumbs up for using languages to their strengths, mighty programmers do that. but i feel sad when tools are not at top notch elegance.

[esam kan]

Junilu Lacar wrote:

esam kan wrote:i would say comments to the rescue here. i write a lot of comments . my code is so clear to anyone reading it. i actually over explain things in my comments , you feel like reading a tutorial .

I would wager that hardly anyone reads your comments, especially the ones that read like a tutorial. Ain't nobody got time for that. Clear, self-documenting code is far better than comments. There are certainly some kinds of comments that are useful but I prefer reading clear code that reveals its intent over reading gratuitously commented code. Show me some "well-commented" code and I could probably show you an uncommented version of it that reads better.

i am not expert but i have read several books that say the opposite. all authors swear by comments.

for me i find that they save time because when i come to read my class in a 6 month period i can comprehend my comments much faster than reading code.

[Tim Holloway]

I swear by comments, too. Even before Donald Knuth made the term "literate programming" popular, my normal coding style for high-level languages was to write an abstract about what the function was for, then write a set of comments describing step-by-step how it did it. I even had a script that was a sort of precursor to JavaDocs.

Nevertheless, when you're running around in the madhouse that's a production environment, you don't have time to read War and Peace. And modern-day IDEs have a very nice "hover" feature that can present small blocks of javadoc when you arrow over code. Which is an incentive to keep things short. Put in all the detail you want, but what the developer wants first and foremost is a terse Executive Summary. Digging into the fine points can wait.

I have a long history with C and C++. In fact, I created one of the very first commercial C++ development systems. But I don't use C++ much any more, because as one pundit said: "Java is C++ without the mace and knives". A large part of the "mace and knives" in C++ came from how you could royally screw yourself with type leakage on pointers. Which is basically what tuples are.

Tuples as an abstract mathematical concept are important. And tuples on quick-and-dirty languages are very convenient. But tuples (including arrays of heterogeneous types) are not supported (as pure tuples) or encouraged (as arrays) in Java, because Java is designed for a more rigorous environment where you do all your work at compile time to minimize the "gotchas" that can spring up at run time. As someone just mentioned, a "tuple" is just a lazy sloppy way of defining an anonymous class on the fly. And while Java has gotten more tolerant of such things in the form of lambdas, they're not yet ready to get that casual.

[Junilu Lacar]

I don't want to stray too much from the OP's topic so I'll be brief about the comments thing. I reiterate: I'm not against comments. Good comments are very useful. The problem is that the vast majority of comments written are not good. Here's an excerpt from the "Clean Code" book by Robert Martin, aka "Uncle Bob" (emphasis mine):

Uncle Bob wrote:One of the more common motivations for writing comments is bad code. We write a module and we know it is confusing and disorganized. We know it’s a mess. So we say to ourselves, “Ooh, I’d better comment that!” No! You’d better clean it!

[Mike. J. Thompson]

Junilu Lacar wrote:I don't want to stray too much from the OP's topic so I'll be brief about the comments thing. I reiterate: I'm not against comments. Good comments are very useful. The problem is that the vast majority of comments written are not good. Here's an excerpt from the "Clean Code" book by Robert Martin, aka "Uncle Bob" (emphasis mine):

Uncle Bob wrote:One of the more common motivations for writing comments is bad code. We write a module and we know it is confusing and disorganized. We know it’s a mess. So we say to ourselves, “Ooh, I’d better comment that!” No! You’d better clean it!

With you 100% on this. The only time I online comments in code is when I'm implementing something from an external standard such as an RFC, or I'm doing something 'odd' to work around a bug or deficiency in code I have no control over. Striving for code that reads naturally is an important goal in my opinion. And I think this does link nicely into the OP's topic, because Tuples in a statically typed language force you to write boilerplate type information in place of more descriptive domain information (such as a class with a descriptive name). That clutters the code, and makes it less readable.

Languages that use duck typing don't suffer from this boilerplate, and actually become more readable with tuples in my opinion.

[Mike. J. Thompson]

Tim Holloway wrote:

I have a long history with C and C++. In fact, I created one of the very first commercial C++ development systems. But I don't use C++ much any more, because as one pundit said: "Java is C++ without the mace and knives". A large part of the "mace and knives" in C++ came from how you could royally screw yourself with type leakage on pointers. Which is basically what tuples are.

C++ has moved on a fair bit in recent years with C++11 and greater. There's no longer any excuse for using raw pointers, or even using the new and delete keyword. You can still screw yourself to your hearts content if you want to, but not without ignoring the 'correct' way of doing things. I've used it for a few things this year and it really was a nice language to use and is now quite difficult to do dangerous things accidentally. It still has some of the most incomprehensible compiler errors I've ever seen though...

Tim Holloway wrote:
Tuples as an abstract mathematical concept are important. And tuples on quick-and-dirty languages are very convenient. But tuples (including arrays of heterogeneous types) are not supported (as pure tuples) or encouraged (as arrays) in Java, because Java is designed for a more rigorous environment where you do all your work at compile time to minimize the "gotchas" that can spring up at run time. As someone just mentioned, a "tuple" is just a lazy sloppy way of defining an anonymous class on the fly. And while Java has gotten more tolerant of such things in the form of lambdas, they're not yet ready to get that casual.

I think it's a little unfair to call languages like Python quick and dirty. They've followed a different paradigm to Java and C++ etc, but they're far from dirty. Some of the cleanest code I've produced has been in Python, and it's allowed me to do things that I wouldn't even bother attempting in Java or C++ because it would take too long. I'm not talking about scripts here either, but 'proper' programs. Duck typing certainly has some drawbacks (for example it means you get less auto-completion support from the IDE, although they're getting better at that), but I haven't encountered any more gotchas at runtime in Python than I have in Java. In fact in some areas Python protects the programmer from making mistakes where Java leaves programmers to follow best-practice on their own or face the consequences. It's all swings and roundabouts in my opinion.

I think the problem comes when a programmer moves between languages but tries to use the new language as if it was the old language (especially when the languages have different paradigms at their heart). They end up with non-idiomatic code that feels clunky and doesn't use the strengths of the language, and then people conclude that the new language is no good. I saw a great talk on Youtube by Raymond Hettinger that was pretty much on this topic.

I'm definitely guilty of this myself, especially when it comes to Pythons idiom of extending classes to provide specialization which in Java would result in bad design. But then inheritance in Python works differently to inheritance in Java so what would be bad design in Java does not translate to bad design in Python.

[Junilu Lacar]

Mike. J. Thompson wrote:
Some of the cleanest code I've produced has been in Python, and it's allowed me to do things that I wouldn't even bother attempting in Java or C++ because it would take too long. ...

I think the problem comes when a programmer moves between languages but tries to use the new language as if it was the old language (especially when the languages have different paradigms at their heart). They end up with non-idiomatic code that feels clunky and doesn't use the strengths of the language, and then people conclude that the new language is no good. I saw a great talk on Youtube by Raymond Hettinger that was pretty much on this topic.

I'm definitely guilty of this myself, especially when it comes to Pythons idiom of extending classes to provide specialization which in Java would result in bad design. But then inheritance in Python works differently to inheritance in Java so what would be bad design in Java does not translate to bad design in Python.

When I was learning Python I was often reminded that it isn't Java. I really like Python and I have seen quite a bit very elegant Python code. At the same time, it's not hard to imagine how bad poorly written Python programs can get but it's the same with any language.

[Campbell Ritchie]

Becoming too difficult a question for “beginning”. Moving. Let's try JiG and General Computing.

[Rob Spoor]

esam kan wrote:i would say comments to the rescue here. i write a lot of comments . my code is so clear to anyone reading it. i actually over explain things in my comments , you feel like reading a tutorial .

The problem with tuples is that the documentation must be on the method that takes / returns the tuple, not on the tuple itself. Once a tuple is returned from a method, it is detached from the documentation that describes what each member means. If the tuple is used just a few lines further on in the same method, you have to go back to the method call that produced the tuple to get to its documentation. That's not really good. With a dedicated class the documentation stays with the object.

If you say I'm exaggerating, I worked on a project that used Pairs and Triples from Apache Commons, and I wasn't the only one on the team that disliked them.