A write-through Converter.convertAll(List)

[gissuebot]

Original issue created by pfnguyen on 2012-05-01 at 05:07 PM

---

From javadoc for Lists.transform:

"Since functions are not reversible, the transform is one-way and new items cannot be stored in the returned list. The add, addAll and set methods are unsupported in the returned list."

Removal operations are still supported.

I would very much like to have a seamless insertion functionality as well; this could be easily implemented by adding an optional third argument to transform, "reverseTransform"

e.g.

public <A,B> List<B> Lists.transform(List<A>, Function<A,B> forward, Function<B,A> reverse);

where reverse is nullable and an overload exists for the original 2 parameter form.

Of course, all the insertions methods in the resultant collections would need to be overridden to perform the reverse transform as necessary.

[gissuebot]

Original comment posted by wasserman.louis on 2012-05-01 at 05:19 PM

---

This is more or less the same as issue 970 and issue 219.

[gissuebot]

Original comment posted by pfnguyen on 2012-05-01 at 05:25 PM

---

So the basic answer is to wait for Converter to be open-sourced, what's an ETA on this? If it's relatively soonish, I'd rather not go and implement this myself.

[gissuebot]

Original comment posted by wasserman.louis on 2012-05-01 at 05:29 PM

---

The last I heard, it was a pretty long ways off.

Do you have an actual specific use case? We might be able to suggest a better solution.

---

Labels: Type-Enhancement

[gissuebot]

Original comment posted by pfnguyen on 2012-05-01 at 05:33 PM

---

I have a list of backing data that is transformed for presentation and front-end use. The front end wants to be able to persist changes to the backend, but only using the front-end model objects.

I would like allow the user of my api to insert, reorder and append model objects that are automatically converted into the backing data format.

I don't want to have a parallel add api nor risk the user of my returned list hitting an UnsupportedOperationException by doing something that's not documented to work.

[gissuebot]

Original comment posted by [email protected] on 2012-05-01 at 10:06 PM

---

Issue 177 covers releasing Converter, including methods convertAll(Iterable) and convertAll(Iterator). It also mentions that adding convertAll(Collection) and/or convertAll(List) would be mildly convenient, but didn't point out the possibility that the latter could be write-through.

The tragic part is that, with Converter in common.base, those methods would not be able to make use of anything in common.collect. But we could still shift gears and go with Lists.transform(List, Converter)...

I have reservations about whether this is really all still within the bounds of normal Collection behavior, or if this is crossing that ill-defined line beyond which lies unpredictable, surprising code. In general, the more I've worked with collections, the more I have come to want a collection to be "just a collection", not trying to do fancy things behind the scenes. I'll just leave it at that for now.

---

Status: Acknowledged
Labels: Package-Collect

[gissuebot]

Original comment posted by pfnguyen on 2012-05-02 at 04:36 AM

---

I understand what you mean, I ran into some surprising behavior if some of the conversions aren't memoized. (Although this was in the normal case and not reverse).

[gissuebot]

Original comment posted by wasserman.louis on 2012-05-03 at 04:17 PM

---

(No comment entered for this change.)

---

Blocked On: #177

[gissuebot]

Original comment posted by [email protected] on 2012-05-10 at 06:42 PM

---

(No comment entered for this change.)

---

Owner: [email protected]

[gissuebot]

Original comment posted by [email protected] on 2012-05-10 at 11:15 PM

---

First, I don't think we should even consider this unless we introduce a more specific InvertibleConverter type. A List to which "add(e); contains(e)" returns false is too damn weird a List for me.

But second, even then, I continue to feel that this crosses a certain line. So far our transforming views have just been views; this takes it to a new level. For now, I'm closing, but feel free to add more justification.

---

Status: WontFix