Revisiting primitives in generics: This can *NOT* be delayed for later.

[Lawrence Kesteloot]

Ops.DoubleComparator could be retrofitted to be an empty sub-interface
of Comparator<double> and the version of binarySearch that takes a
DoubleComparator could be removed. The version that takes a Comparator
would work with old binary classes, old source classes, and new source
classes.

Lawrence


On Fri, Jul 16, 2010 at 12:10 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> I realized this rather troublesome problem of going with SotL and not
> considering primitives in generics:
>
> There's no way back from that.
>
> If ParallelArrays is released with the full contingent of 132 SAMs in Ops,
> then we'll not only be stuck with them forever in the traditional sense of
> not eliminating classes to preserve backwards compatibility, but there's
> also no practical way forward, either.
>
> Currently, PA's DoubleParallelArray has a binarySearch method with the
> following signature:
>
> binarySearch(double target, Ops.DoubleComparator c).
>
> DoubleComparator itself is a SAM type, with signature #int(double, double).
>
> Therefore, a call to binarySearch with lambda would look like:
>
> binarySearch(12345678.9, {double a, double b -> Math.abs(a)-Math.abs(b)});
>
>
> But if in a later JDK there's a way to deprecate Ops.DoubleComparator in
> favour of either a function type #int(double, double), -OR- my preferred
> option of allowing java.util.Comparator<double>, then there would be a
> second binarySearch method with signature:
>
> binarySearch(double target, Comparator<double> c).
>
> Calling this one would look like:
>
> binarySearch(12345678.9, {double a, double b -> Math.abs(a)-Math.abs(b)});
>
> which is indistinguishable from the Ops.DoubleComparator case. The compiler
> can therefore not compile it, complaining about ambiguity. Users would have
> to explicitly specify either Ops.DoubleComparator or Comparator<double>,
> breaking backwards compatibility and in general uglying up the API.
>
> I don't see a nice solution for this dilemma; one could use 'binarySearch2'
> but that feels like a copout. One could attempt a scheme whereby overridden
> methods can use some extra keyword to dictate to the compiler which of a set
> is to be preferred in case there's ambiguity, but that's adding extra
> complexity, which may not be palatable at that point.
>
>  --Reinier Zwitserloot
>
>