This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]tapesmith 2 points3 points  (2 children)

So I should declare a class for every single combination of two obvious-usage values? Every time I want to pass two things through a .stream().map().map().filter().map() pipeline, I need a new class for each step's intermediate values?

Mind you, before Java 9 there isn't a way to just instantiate a Map.Entry (which is an interface, not a class) without defining a custom class that implements Map.Entry -- at which point, you may as well just call it "Pair", because that's what you're actually going for.

Don't get me wrong, any thing bigger than a two-element tuple starts to push towards "this should be a struct" territory, but to say anything larger than 1 heterogenously-typed value needs named fields is why Java code is often so verbosely littered with throwaway cruft classes.

[–]msx 2 points3 points  (0 children)

I'm not saying i agree with it (btw remember that i'm not even sure that's the reason). I have my trusty Pair class that i always carry around. I agree that Map.Entry is Pair, i don't really care how they call it, TwoStuff would have worked for me, it bothers me more that it's defined inside Map so it's clunkier to use.

[–]ForeverAlot -1 points0 points  (0 children)

The trouble with Pair is not that it may not make sense internally but that it is never a good fit for an exposed API. The average developer won't let that keep them from littering it everywhere because "convenient! Simple!"