Coercing<T> should be Coercing<I, O> ?

[dminkovsky]

Left a comment on the commit that generified Coercing. Think opening an issue makes sense:

Coercing does different things in serialize() vs parseValue() and parseLiteral():

• Results of serialize() are destined for ExecutionResults and further down: serialization.
• Results of parseValue() and parseLiteral() are used at runtime inside data fetchers.

I would say this class should be broken up into Coercing<I, O> ,where I and O are:

• The input runtime type if the scalar is being used as an input type, and
• The output serialized type of the scalar is being used as an output type,

respectively.

[dminkovsky]

I think some of the confusion regarding this class stems from the fact that most (if not all) of the built-in scalars call and return the result of serialize() from the parse methods.

This is just an implementation detail of the built-in scalars and the nature of those scalars themselves—serialization and parsing behavior are desired to be the same.

But if you are implementing your own scalars, you may want the parse behavior to transform a simple type into a more complex type, and then serialization to transform a complex type into a simpler or more common type (say, a type that is well-known to Jackson).

[dminkovsky]

For example, I have a class that provides a base for input-only scalars:

import graphql.schema.Coercing;

public abstract class InputCoercing<I> implements Coercing<I, Void> {
    /**
     * Input scalars should not be serialized
     * @param input the input object
     * @return always null
     */
    @Override
    public final Void serialize(Object input) {
        return null;
    }
}