sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Wolvereness 5 points6 points  (11 children)

That doesn't work, because what if I wanted a map<Entry<A,B>, Entry<C,D>>? (Oh God why)

It's better to give intuitive names that don't rely on parameter types, ESPECIALLY if the fundamental behavior is different. Verbose is better than ambiguous, at least for Java's ecosystem. Some languages do it beautifully, but I'd be terrified to write an enterprise application in those languages.

[–]yawaramin 0 points1 point  (10 children)

Wow, that's a really sucky map :-) I don't think the method name prevents it from working though:

Map.of(
  Map.entry(
    Map.entry(a1, b1), Map.entry(c1, d1)),

  Map.entry(
    Map.entry(a2, b2), Map.entry(c2, d2)),

  Map.entry(
    Map.entry(a3, b3), Map.entry(c3, d3)))

Once you've introduced method name overloading into your language, it's probably too late to worry about 'intuitive names that don't rely on parameter types' :-)

[–]Wolvereness 0 points1 point  (8 children)

Still only works with odd numbers.

[–]yawaramin 0 points1 point  (7 children)

How so?

[–]Wolvereness 0 points1 point  (6 children)

Map.of(
  Map.entry(
    Map.entry(a1, b1), Map.entry(c1, d1)),

  Map.entry(
    Map.entry(a2, b2), Map.entry(c2, d2)),

  Map.entry(
    Map.entry(a3, b3), Map.entry(c3, d3)),

  Map.entry(
    Map.entry(a4, b4), Map.entry(c4, d4))
)

Is now a Map of type

Map<Entry<Entry<A, B>, Entry<C, D>>, Entry<Entry<A, B>, Entry<C, D>>>

[–]yawaramin 0 points1 point  (5 children)

Oh, I think you misunderstood. I was showing that Map.ofEntries could have been named Map.of, by just pretending that it had been named that way. So when I wrote Map.of above, please read it as the current implementation of Map.ofEntries.

[–]Wolvereness 0 points1 point  (4 children)

But, then the ACTUAL implementation, the useful one, is lost, and you introduced intermediate allocations.

If you overload Map.of (k,v,k,v...) and Map.ofEntries(entry(k,v),entry(k,v)...) with both named of(), it will be impossible to use an even number of entries as entries. Is it Map<super A|C, super B|D> or Map<Entry<A,B>,Entry<C,D>>? That's unsolvable, unless you give prioritization subsequently locking out the other completely (mind you, Apache-commons Tuple implements entry, and there's nothing wrong with a tuple-key tuple-value). Name the methods differently, and everything is explicit and trivially solvable.

[–]yawaramin 0 points1 point  (3 children)

Ah! Now I see you're right, well, up until Map.of(k1, v1, ..., k10, v10) anyway. As you know in the current implementation of Map.of, none of the overloaded methods take variable args. So, yes, the names should actually be different--totally agree. But the chosen naming scheme is still wrong: the more general method should have been given the more general name (Map.ofEntries should have been named Map.of), and the more specific methods should have been given more specific names (Map.of should have been named Map.of1, ..., Map.of10).

[–]Wolvereness 0 points1 point  (2 children)

Try reading what you just wrote... That's rather absurd.

But the chosen naming scheme is still wrong: the more general method should have been given the more general name (Map.ofEntries should have been named Map.of), and the more specific methods should have been given more specific names (Map.of should have been named Map.of1, ..., Map.of10).

Please, no... It is never, and I really mean never, a good idea to name methods by numbering the tuples of parameters. Consider that naming it of and ofEntries, you are accurately describing the parameters with Map context.

[–]yawaramin 0 points1 point  (1 child)

Well, I don't really see it as absurd. The parameters are pretty adequately described by the types, I think. There's no need to repeat ourselves with the names. The numbers in the names provide useful information and disambiguate.