Lightweight interfaces instead of function types

[Stephen Colebourne]

On 19 February 2010 23:27, Mark Thornton <mthornton at optrak.co.uk> wrote:
> It is the ones which enumerate their primitive type parameters that smell
> (and constitute most of the 81 as result of the combinatorial explosion of
> possibilities).

I did consider whether this might be handled more cleverly by allowing
the lightweight interface to auto-generate multiple real interfaces
(or one with more than one method). (ie. for Reducer to automatically
handle the combinations of primitive types) I suspect getting this to
work would be tricky...

I'd also note that fork-join will probably need multiple versions of
the implementation code anyway in order to make use of any primitives
passed in, so the issue does seem slightly moot.

One alternative option is to consider the lightweight interface to
have a name scoped to the associated method. Fork-join has this:

 static Ops.LongPredicate andPredicate(Ops.LongPredicate first,
Ops.LongPredicate second) {...}
 static Ops.DoublePredicate andPredicate(Ops.DoublePredicate first,
Ops.DoublePredicate second) {...}

whereas with method-scoped lightweight interface names you could write:

 interface Predicate boolean(long)
 static Predicate andPredicate(Predicate first, Predicate second) {...}

 interface Predicate boolean(double)
 static Predicate andPredicate(Predicate first, Predicate second) {...}

With the compiler renaming the matching interfaces to make them
unique. Of course this is close to function types (which just embed
the signature). I raise it to show that there are ways to avoid
writing the 81interfaces up front (by writing it on demand). As
always, the route this project takes is a choice.

(To be clear, I agree that the interfaces should describe what they
do, not what the argument types are. However, this isn't a simple
problem to solve - every option has a compromise)

Stephen