Sets.transform(Set<F>, Converter<F, T>) or the equivalent - WontFix: Use ImmutableSet.copyOf(Collections2.transform(...))

[gissuebot]

Original issue created by butkovic on 2009-08-13 at 11:52 AM

---

I'd like to use method:
Sets.transform(Set<F> fromSet, Function<? super F,? extends T> function)

But there is no such method. I would expect it would behave the way similar
to one in List.transform()

thanks.

Peter B.

[gissuebot]

Original comment posted by jim.andreou on 2009-08-13 at 11:59 AM

---

How would you implement Set<T>.contains(Object) in the resulting set? (Or if that set
was not lazy, you wouldn't need this method). Well, you would need the inverse function
T --> F as well (which would imply that such an inverse function exists). So it's
lost more complicated than that, and I'm not sure that's the only issue.

[gissuebot]

Original comment posted by butkovic on 2009-08-13 at 12:11 PM

---

I didn't notice it's implemented lazy for list, sorry, only now I checked the sources.
OK, that's probably too much complicated then.

[gissuebot]

Original comment posted by jared.l.levy on 2009-08-13 at 01:57 PM

---

Sets.transform isn't feasible. The problem is that the function could map two distinct
elements in fromSet to the same value, which would violate the requirement that all
elements in the returned set must be unique.

Instead, you can pass a set to Collections2.transform(). If you need a set at output,
copy the collection generated by Collections2.transform() into a set.

---

Status: WontFix

[gissuebot]

Original comment posted by jim.andreou on 2009-08-13 at 02:13 PM

---

To complement Jared response, he describes a situation where there wouldn't exist an
inverse function.

But we should note that if there was a "Bijection" interface, which defined both
directions of a function, such a transform method would be easily defined in terms of
that.

[gissuebot]

Original comment posted by joe.kearney%morganst...@gtempaccount.com on 2009-08-13 at 02:29 PM

---

I have a use case for this, where I'm trying to implement a Map. I want the keySet to
be a view over the EntrySet, not just a copy. In this (admittedly limited) scenario
we have the advantage of being able to guarantee that the transformed elements will
indeed be unique. The function here would simply be to pull out the key from the
entry. Of course, as Jim Andreou points out above, you'd need a little more
cleverness for contains(Object), remove etc, but these could be achieved by a
function that boils down to key->underlyingMap.getEntry(key).

The simplest solution is to extend AbstractSet and implement iterator() using
Iterators.transform, but then most operations degenerate to a linear trawl, and I
can't easily delegate back to the entrySet/underlying map to do the work.

What would you recommend to implement this? Just a fuller implementation of
AbstractSet? Would there be any scope for requiring the inverse function to be given?
You'd shift the burden for guaranteeing correctness to the implementation of the
functions, but would only need it to be valid over the domain of the contents of the set.

Set<F> transform(Set<F> fromSet, Function<? super F,? extends T> function, Function<?
extends T,? super F> inverse) // generics would need more thought

I realise that this would be a rather complex addition at this stage, but I'd be
interested to hear others' thoughts. My point is that though this won't work in
general, there is a class of cases where you can provide the required guarantees such
that it could be well-defined and indeed useful.

Thanks,
Joe

[gissuebot]

Original comment posted by cpovirk+external@google.com on 2009-08-13 at 03:12 PM

---

Joe, what features do you need that AbstractMap.keySet() doesn't provide? A fast
remove()? The ability to easily use the keySet() implementation without extending
AbstractMap?

[gissuebot]

Original comment posted by joe.kearney%morganst...@gtempaccount.com on 2009-08-13 at 03:38 PM

---

Yes, sort of. I'm not using AbstractMap, but in any case that implementation of
keySet() just creates an AbstractSet over the keys in the entrySet iterator, so most
operations are still linear.

We're not using an AbstractMap for slightly obscure memory reasons, we're optimising
for a slightly unfortunate case we have where we see a vast number of small or empty
maps. The keySet and entrySet fields from AbstractMap turned out to be a noticeable
chunk of the memory used. It's an array-backed map akin to the LinearMap suggestion
in another bug report. The reason I'm still looking for better-than-linear
performance in the key-set methods is that we're using a binary search over the
(Comparable) keys. Maybe LogarithmicMap would have been better...

I don't think it's particularly complex to just delegate everything back to the
underlying map and translate the details, it would just be nice to have a utility to
do it for me. Then again, maybe this doesn't come up that often.

[gissuebot]

Original comment posted by kevinb9n on 2009-11-04 at 11:04 PM

---

Reopening, because in the future we likely will have an invertible Function (we call
it Converter, for better or worse), and when we do, this method is worth considering.
It would simply have to document that your converter had darn well better be a strict
bijection (so no String<->Double or things like that!).

---

Status: Accepted
Labels: Milestone-Post1.0

[gissuebot]

Original comment posted by kevinb@google.com on 2010-02-12 at 05:06 PM

---

Upon further discussion, I'm coming to the same conclusion that I had a few years ago
when Sets.transform() was first requested: nearly every conceptually invertible
function is lossy; truly lossless (mathematically invertible) ones are vanishingly
rare. The result could be a broken Set. That doesn't mean we'll definitely never do
Sets.transform(), but its priority feels low for this reason.

[gissuebot]

Original comment posted by kevinb@google.com on 2010-04-23 at 08:27 PM

---

note: depends on bug 177.

[gissuebot]

Original comment posted by kevinb@google.com on 2010-07-30 at 03:53 AM

---

(No comment entered for this change.)

---

Labels: -Milestone-Post1.0

[gissuebot]

Original comment posted by fry@google.com on 2011-01-26 at 10:11 PM

---

(No comment entered for this change.)

---

Labels: Type-Enhancement

[gissuebot]

Original comment posted by maliniakh on 2011-02-02 at 01:04 PM

---

@Kevinb: Developers may be aware that some sets are truly lossless, like converting db entities into their ids. If sets happen to be lossy, simply runtime exception could be thrown within Sets.transform() method. Sounds like a reasonable solution to me.

[gissuebot]

Original comment posted by kevinb@google.com on 2011-02-02 at 03:03 PM

---

We wouldn't be able to throw such an exception; we wouldn't know there was anything wrong. It would just produce a buggy Set. Again, we're not rejecting the idea and it will probably happen eventually.

[gissuebot]

Original comment posted by finnw1 on 2011-02-02 at 04:42 PM

---

I think that's an example of where lossiness does not matter. If a DB entity has been deleted, yes regenerating it from its id will fail, but then the object must have been invalidated already (even if the fact was not known.)