To extend Function or not to extend Function

[AMendenhall]

Consider the following case:
You want to make an interface which forces the functionality of being interpolable, that is, being able to be interpolated. You'd probably start off with the following code

public interface Interpolable {
/**
* Interpolates this value and @param a
*/
public Interpolable interpolate(Interpolable a);
}

Herein lies the 1st problem:
If the interpolate method accepts a, of type Interpolable, and returns some Interpolable, then any implementing class could accept and return any other implementing class. Desired functionality would limit both of these to only the type of the class which is doing the implementing.
My solution:

public interface Interpolable<T extends Interpolable<T>> {
/**
* Interpolates this value and @param a
*/
public T interpolate(T a);
}

This way, any class which implements interpolable must specify that the generic type T is itself, that is, the method interpolate accepts and returns only itself. Problem is, an imposter class could lie and say that it accepts and returns a different interpolable type. Is there a more elegant way to do this?

Say you also want your Interpolable interface extend UnaryOperator, because it takes in an Object and returns an Object, both of which are of type T. However, the method required by UnaryOperator is T apply(T a). A way to get around that would be to make Interpolable an abstract class and make the method interpolate call apply. Are there more elegant ways to do this?

public abstract class Interpolable<T extends Interpolable<T>> implements UnaryOperator<T> {
/**
* Interpolates this value and @param a
*/
public T interpolate(T a) {
return apply(a);
}
}


I know this isn't super FRC oreinted, but I'm still using it for some cool robotics stuff that I think I'll release sometime this summer. Thanks for any replies.

[euhlmann]

Why do you need to restrict "imposter" classes? I think your second code block has the best solution.

[GeeTwo]

Why do you need to restrict "imposter" classes? I think your second code block has the best solution.

Concur. The purpose of the interface is to allow a totally distinct implementation of the interface contract. While I agree that there is no clear way for an interface to enforce a contract, it is only trivially more difficult to "break the contract" for a class which extends a base class. (How many times have programmers overridden object.equals to mean something quite different than "is-another-handle-for-the-same-object"?)

[RyanCahoon]

+1 to what has already been said. It's up to each code implementor to ensure that the proper functionality is in place, and up to reach consumer of code that others have written to ensure that code does what they want.

To offer concrete proof that this isn't possible in Java:

Suppose there were a way to enforce what you're asking for
public interface A<T> /* magic that requires subclass of A to use itself as the type parameter */ {
public T interpolate(T a);
}
Since there's no way in Java to require a subclass to be final, nothing prevents a malicious user from doing the following
class B extends A<B> {
public B interpolate(B a){
// implementation
}
}

class C extends B {}
at this point, C is equivalent to
class C extends A<B>

[AMendenhall]

Makes sense. Thanks for the reply