Convenience for Functions on single domain

[GoogleCodeExporter]

Hi,

when writing anonymous inner Functions, I found myself often writing 
Function<Iterable<Integer>, Iterable<Integer>> - or other Functions with both 
type arguments the same. This adds much unnecessary code, which is undesirable 
especially when defining anonymous inner classes.

Proposed enhancement is super simple, add this interface:

public interface Permutation<T> extends Function<T, T> {

}

As for the name, I used math terminology 
(http://en.wikipedia.org/wiki/Bijection), but saw Function1<T> in the wild.

Original issue reported on code.google.com by gscerbak@gmail.com on 5 May 2011 at 9:57

[GoogleCodeExporter]

We've implemented this locally, although we called it "processor" because thats 
how we viewed it at the time. It would be immensely useful to have though, and 
since it builds on Function it works with just about everything function works 
with.

Original comment by bj...@soldal.org on 6 May 2011 at 1:19

[GoogleCodeExporter]

(A Function<T, T> would only be a "permutation" if it was bijective, which few 
functions are.)

I don't see a problem with users making little shim interfaces like this 
yourselves -- unless having this type in Guava would enable Guava to also 
provide some new useful functionality?

Original comment by kevinb@google.com on 6 May 2011 at 11:14

[GoogleCodeExporter]

As far as I know in Java it is not easy to make a method/Function explicitly 
not bijective - if it has one parameter of the same type as its return type. So 
for me it is better to assume it can be. However I couldn't find a better name, 
that would be general enough.

Sure, this interface is really just a one line of code:). However, unlike the 
famous Pair class, this has nice semantics semantics and it makes no sense to 
create the exact same thing over and over again - it makes no sense to add 
anything.

It provides no new functionality, the point is simply to avoid repeating the 
type information, which happens occasionally also in guava libraries. I came to 
it when I was writing unfold on Iterables, simple Iterable based on the 
AbstractLinkedIterator: 

public static final <T> Iterable<T> unfold(final T first, final Function<T, T> 
computeNext)

This obviously leads to many "Permutations". The reason why I mention this is 
that it allows to simply implement the Range people are asking for, just using 
guava's Iterables.limit and Iterables.skip methods. Actually it enables 
infinite Iterables, which can be defined recursively. By applying few 
Iterable.transform etc. I was able to simply write fold method - aggregation, 
which has been discussed here as well.

As I mentioned before, I saw this in someones else's code as well. So I guess 
this is something many guava users will eventually stumble upon.

Does this make sense? Does it sound at least a bit convincing?:)

Original comment by gscerbak@gmail.com on 6 May 2011 at 11:47

[GoogleCodeExporter]

According to this: 

http://en.wiktionary.org/wiki/endofunction

endofunction is the name I am looking for...

Original comment by gscerbak@gmail.com on 6 May 2011 at 11:59

[GoogleCodeExporter]

Original comment by kevinb@google.com on 13 Jul 2011 at 7:24

• Changed state: Triaged

[GoogleCodeExporter]

Original comment by kevinb@google.com on 13 Jul 2011 at 7:27

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by cpov...@google.com on 13 Jul 2011 at 7:42

• Changed title: Convenience for Functions on single domain

[GoogleCodeExporter]

Original comment by fry@google.com on 10 Dec 2011 at 4:08

• Added labels: Package-Base

[GoogleCodeExporter]

We are not convinced there's nearly enough value in adding an Endofunction<T> 
interface just as, basically, shorthand for Function<T, T>.

Original comment by kevinb@google.com on 16 Feb 2012 at 7:08

• Changed state: WontFix

[GoogleCodeExporter]

This issue has been migrated to GitHub.

It can be found at https://github.com/google/guava/issues/<id>

Original comment by cgdecker@google.com on 1 Nov 2014 at 4:15

• Added labels: MigratedToGitHub

[GoogleCodeExporter]

Original comment by cgdecker@google.com on 3 Nov 2014 at 9:09

• Added labels: Restrict-AddIssueComment-Commit