Closed GoogleCodeExporter closed 8 years ago
I can see this happening eventually. It's a little problematic because so many
functions that have an inverse() function are not actually invertible in the
mathmetical sense (for example, you can convert "1.00" to a double and get 1.0,
then
back to a String and get 1.0), and as a result, the kinds of things you expect
to be
able to do with an invertible function (like Sets.transform(Set)) aren't really
ironclad.
I think we can work out how to warn about the minor risks though.
Original comment by kevin...@gmail.com
on 29 May 2009 at 6:54
I just realized that we have actually implemented this already internally, but
we
have named it "Converter."
How would users feel if our InvertibleFunction class were named Converter
instead?
Also, it's an abstract class instead of an interface so that it can have useful
methods on it like convertAll() (aka transform()). That's inconsistent with
our
other types, but it is quite nice...
Original comment by kevin...@gmail.com
on 17 Sep 2009 at 5:33
Original comment by kevin...@gmail.com
on 17 Sep 2009 at 5:34
Original comment by kevin...@gmail.com
on 17 Sep 2009 at 5:45
Original comment by kevin...@gmail.com
on 17 Sep 2009 at 5:57
Could Converter<T,K> be made to implement InvertibleFunction<T,K>. Then you can
implement an interface as an option. The naming would be fine.
Thanks,
Eric
Original comment by ejwin...@gmail.com
on 17 Sep 2009 at 6:16
Definitely make Converter implements InvertibleFunction.
IdentityFunction is one implementation :).
Original comment by stephen....@gmail.com
on 3 Dec 2009 at 1:51
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
ejwin...@gmail.com
on 29 May 2009 at 6:48