This question already has an answer here:

I strongly suspect that this sort of question has been asked before (of course I looked at what came up) ... and answers like "life's not fair" may well apply.

I'm thinking of this answer : the user in question (who I apologise for singling out) has a vote of 247 which basically constitutes virtually his/her entire rep of 2.6 k.

The answer is OK... but I would qualify it as naive: the answerer just doesn't understand the intricacies of the logic of obtaining an element from a Java Set. NB disclaimer: I have just added my own answer to this question.

Is anyone at all bothered by this sort of thing? It just seems ... problematic (!) to me.

marked as duplicate by approxiblue, Stephen Rauch, Blackwood, HaveNoDisplayName, 1615903 Mar 21 '17 at 5:17


  • 3
    I'm more bothered that there is now a "naive-answers" tag on Meta... – Heretic Monkey Mar 20 '17 at 21:37
  • 3
    Users upvote what they find useful. Can't really... negate opinions other than by casting your own. – Kevin B Mar 20 '17 at 21:37
  • @Mike McCaughan why? (3 seconds later) Oh, gone! OK... – mike rodent Mar 20 '17 at 21:38
  • 2
    Overmeta related: Life isn't fair – Travis J Mar 20 '17 at 21:38
  • 1
    Some of Stack Overflow's storied history is on Meta Stack Exchange. Here is another one which is similar: Fastest Gun in the West Problem – Travis J Mar 20 '17 at 21:44
  • 2
    Mostly because "naive-answers" is not a good way of categorizing your question. See more at tagging, but basically, you should always prefer using existing tags rather than creating new ones. We have the answers tag which covers, well, answers and is more than suitable for categorizing the question. – Heretic Monkey Mar 20 '17 at 21:46
  • @TravisJ It was (well) worth my posting this question (which I fully expect to be destroyed) just to see your Bardic soliloquy! – mike rodent Mar 20 '17 at 21:46
  • @MikeMcCaughan OK... well on SO (normal) I recently went over the 1500 rep, which I believe gives me the theoretical chance to create new tags... and it look likes it extends to Meta... so I thought I'd chance my arm ;-) – mike rodent Mar 20 '17 at 21:50
  • Hah, thanks :) It isn't a bad question to post, it is just part of the system design that this happens. Many other users have also pointed out before that there are problems with the "best answers bubble" approach. However, the times that the best answer does not bubble up are luckily far less common than the times when they actually do. As a result, fundamentally changing the system to accommodate an outlier hasn't been a priority. Moreover, tracking votes by date is resource intensive, which would be required in order to sort by vote velocity instead of total vote distance. – Travis J Mar 20 '17 at 21:51
  • 3
    Yeah, I guess what I'm trying to say is, just because you have the privilege to do so, doesn't mean you should. I've got >5000 rep and been over 1500 for quite a while, and have never created a tag, because I know that tag cleanup can be a real pain, and there's always an existing tag that covers my categorization needs. – Heretic Monkey Mar 20 '17 at 21:56
  • 1
    I have over 11.2k rep and have never created a tag (as far as I can remember) – user4639281 Mar 20 '17 at 21:58
  • @MM & TG Understood. – mike rodent Mar 20 '17 at 22:06
  • 1
    @approxiblue similar, certainly... but the answer I referenced isn't wrong so much as naive... though no doubt much the same "best response" applies... – mike rodent Mar 20 '17 at 23:55
  • I have 15K+ rep... what's a tag? :P – zer00ne Sep 9 '17 at 12:31

Did you even stop to consider whether the 200+ users who voted for that answer know something you don't?

You said that


but there's no evidence to support this.

Your answer makes some good points concerning how to build a useful interface on top of the associative collections already available, but that doesn't in any way counter the answer you complained about, which is perfectly correct that it would have been easy for the original implementer to include this capability.

And unless you show some evidence that the Java framework designers considered including a get() method but had some strong reasons for omitting it, I'm inclined to also believe what the answer says about the lack of foresight, namely

They didn't anticipate your very legitimate use case

  • 4
    The answerer there said "because the designers of the collection framework were not very forward looking. They didn't anticipate your very legitimate use case". I disagree with that answer. You are free to agree with it. But please avoid a patronising tone: it doesn't help. – mike rodent Mar 21 '17 at 6:55
  • By the way, having thought about this for a few days, I've realised where the problem lies: it's essentially C programmers who are unwilling or unable to accept the very different "contract" enforced by Java, in terms of object-oriented rigour. So the questioner in that question (and 200+ users who upvoted) have used spurious grounds to "convince themselves" further that Java is rubbish compared to C. It may be "less good" (I don't think so) but the absence of a Set.get() method does not prove that. Quite the contrary: equality is not identity. – mike rodent Mar 26 '17 at 21:06
  • @mikerodent: I can now tell you with confidence what the other 200 users know that you don't. Namely that what the answer says (the authors of the framework didn't think of that) is completely different from the straw man argument you are attacking (Java is rubbish compared to C). The answer doesn't say that or even suggest it. If you have some evidence that (they didn't think of that) is wrong, such as a discussion on a mailing list where it was considered and a decision was made not to have Set.get(), please share. But right now you are attacking the answer for something it doesn't say – Ben Voigt Mar 26 '17 at 22:02
  • Haha. I don't think so. In a comment I asked the answerer in question "Are you thinking of a particular language which does this better?" Reply: "For example std::set in C++ has a find() method that does exactly that". Now maybe you can just, er, drop your annoying attitude "they know sthg you don't"? To repeat: it doesn't help. What are you trying to achieve by that? It just makes me think you're a bit silly. – mike rodent Mar 26 '17 at 23:04
  • @mike: I did see that. It doesn't support your claim (either that the answer lacks understanding of Java Set, or that the answer calls Java rubbish) in the slightest, but it is interesting that he doesn't know that the C++ equivalent of Java Set is not std::set (sorted) but std::unordered_set (hash-based). But you won't clearly understand why people upvote that answer until you read what it actually says instead of trying to impose what you wish it said. – Ben Voigt Mar 27 '17 at 2:37
  • @mikerobent: BTW, your claim that Java has to omit "get()" in order to achieve "object-oriented rigor" doesn't hold up either. If it weren't possible to get access to the original objects added to the set, you could make an argument from encapsulation. But iteration does already give (inefficient) access to the original objects. A get() method doesn't seem to violate any of the other OOP principles such as SOLID either. And a hash lookup does access the original object (it must, to check whether a hash collision occurred) so I don't see any intricacies that the answer misunderstands. – Ben Voigt Mar 27 '17 at 2:46
  • In fact I read that answer and thought about it a great deal before submitting my own answer and posting this question here. I understand perfectly well why people have upvoted that answer (obviously!). I just think they're the naive ones, not the designers of Java ("naively tried to design..."). I didn't know that C's std::set was equiv to SortedSet. In fact Set.contains is named painfully, as I said in a comment: it should be containsEqualTo. – mike rodent Mar 27 '17 at 6:18
  • But TBH I'm getting a bit bored now: you clearly don't agree that (by some means) a Set element class should ideally enforce "equality equals identity" (as in my answer, though obviously we have to wait for Java to finally implement multiple inheritance for this to be enforced rather than just nudged). Not providing a get method was clearly a nudge technique by the Java designers. But if you want to believe, with the answerer, that it was naivety/lack of foresight, that's your right. – mike rodent Mar 27 '17 at 6:22
  • @mikerodent: I think a Set-like class with a get() method that works with any element type is more useful than one that requires invasive changes to the element. It may still be a good idea to make those changes if you control the element type. But there are plenty of types you don't control (provided by either the Java standard library or third-party libraries) that it could make sense to place into such a Set-like, and use get() for de-duplication. – Ben Voigt Mar 27 '17 at 16:04
  • I can't disagree with that... but clearly the Java designers eschewed that choice. NB obviously you can always wrap an existing class in a NoVisibleConstructor wrapper class, as I suggest in my answer... – mike rodent Mar 27 '17 at 17:55

Not the answer you're looking for? Browse other questions tagged .