Patch/Request: Functions.toStringFunction and related

[GoogleCodeExporter]

I noticed that Functions.toStringFunction() does not return a narrow-type 
object, and that there is no equivalent for hashCode().

I was writing a gating system for use in a decorating throttle system, but it 
required an optional strategy for comparing values, for this I wanted to offer 
the option of entering a function which would take T and return an identifying 
object, be it toString() or hashCode() or something similar.

Here is some proposed code for this;

----------------

public static <I> Function<I, String> toStringFunction() {
        return ToStringFunction.INSTANCE.toNarrowType();
    }

    // enum singleton pattern
    private enum ToStringFunction implements Function<Object, String> {
        INSTANCE;

        public String apply(Object o) {
            checkNotNull(o); // eager for GWT.
            return o.toString();
        }

        @Override
        public String toString() {
            return "toString";
        }

        <I> Function<I, String> toNarrowType() {
            return (Function<I, String>) this;
        }

    }

    public static <I> Function<I, Integer> hashCodeFunction() {
        return HashCodeFunction.INSTANCE.toNarrowType();
    }

    // enum singleton pattern
    private enum HashCodeFunction implements Function<Object, Integer> {
        INSTANCE;

        public Integer apply(Object o) {
            checkNotNull(o); // eager for GWT.
            return o.hashCode();
        }

        @Override
        public String toString() {
            return "hashCode";
        }

        <I> Function<I, Integer> toNarrowType() {
            return (Function<I, Integer>) this;
        }

    }

Original issue reported on code.google.com by bj...@soldal.org on 21 May 2011 at 5:48

[GoogleCodeExporter]

Aren't the Equivalence and Ordering interfaces more suitable for what you are 
trying to achieve?

Original comment by gscerbak@gmail.com on 21 May 2011 at 6:23

[GoogleCodeExporter]

No, because I am using a map in the background to do the gating.

Original comment by bj...@soldal.org on 21 May 2011 at 6:26

[GoogleCodeExporter]

In both cases, it's appropriate for the returned Functions to be 
Function<Object, T> because such a Function can in fact accept any Object. This 
is an example of why most methods with a Function parameter should accept 
Function<? super F, ? extends T> rather than just Function<F, T>.

As far as the addition of hashCodeFunction(), I feel like there'd need to be 
more use cases for it. I don't know anything about your use case, but it 
doesn't sound like a good idea to me to use hash codes as an identifiers for 
objects. Hash codes in general are explicitly not identifiers given that 
collisions between distinct objects are legal and can be rather arbitrary.

Original comment by cgdec...@gmail.com on 22 May 2011 at 4:36

[GoogleCodeExporter]

I disagree, having Functions.toStringFunction() return a narrow-type function 
would let if work better with composition and transformation in user code. 
Having to manually cast it to the correct type looks and feels ugly.

As for hashcode, in my use case we aren't concerned with collisions, and in any 
case it would be useful to have as a generic accessor.

Original comment by bj...@soldal.org on 22 May 2011 at 9:46

[GoogleCodeExporter]

Whatever these "composition and transformation in user code" are, they need to 
learn about proper use of wildcards and type parameters in Java if they are 
having any trouble making use of Functions.toStringFunction() as it is defined. 
 The cases where you need to manually cast it do exist but are so rarely needed 
that a cast is a perfectly acceptable alternative.

As for hashCodeFunction(), we used to have it, almost no one never used it, and 
the users who did use it were all better off doing something else; ergo we got 
rid of it.

Original comment by kevinb@google.com on 22 May 2011 at 2:18

• Changed state: WorkingAsIntended

[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