Closed GoogleCodeExporter closed 8 years ago
Hmm... considering this method plus the three filtering ones, that makes four
methods
we might have to duplicate. I feel ambivalent about that.
An alternative is to create a SortedMaps class to house only the things special
to
SortedMaps -- these four and maybe a scant few other things.
Another possibility -- I don't know if it's a good one -- would be for us to
specify
that if you pass a SortedMap to one of the existing methods, you can safely
downcast
the result back to SortedMap. (and then, you know, do the implementation like
that too.)
Original comment by kevin...@gmail.com
on 6 Nov 2009 at 10:00
In addition, a Sets.filtered() method could handle SortedSets.
I'd rather not force people to cast, since casts are a code smell that should be
avoided when feasible.
Original comment by jared.l....@gmail.com
on 6 Nov 2009 at 6:04
I think you're totally right about that.
Original comment by kevin...@gmail.com
on 6 Nov 2009 at 6:13
My +1 to SortedMaps.transformValues rather than downcasting.
In addition, also this method would be IMHO useful:
<K,V1,V2> SortedMaps.transformEntries(
SortedMap<K,V1> fromMap,
Function<? super Map.Entry<K,V1>,V2> function
)
This is similar to transformValues but new values also depend on key which is
practical when one works with mathematical-function-like data.
Original comment by tomas.za...@gmail.com
on 24 Nov 2009 at 1:15
That transformEntries method is reasonable.
Whoever's interested in it should file a separate issue, so it's not hidden
within
issue.this
Original comment by jared.l....@gmail.com
on 28 Nov 2009 at 8:03
This issue has been moved to the Guava project (keeping the same id number).
Simply replace 'google-collections' with 'guava-libraries' in your address
bar and it should take you there.
Original comment by kevinb@google.com
on 5 Jan 2010 at 11:09
Original issue reported on code.google.com by
tomas.za...@gmail.com
on 6 Nov 2009 at 9:12