[threeten-dev] ChronoLocalDate Generic type parameters (#292)

[Stephen Colebourne]

On 4 April 2013 21:37, roger riggs <roger.riggs at oracle.com> wrote:
> Some alternatives for include:
>
> 1. ChronoLocalDate - no parameterization
> 2. ChronoLocalDate<D extends ChronoLocalDate>
> 3. Removing the <?> from return values.
>
> Though the simplicity of 1) removing the generics seems appealing, it
> disables application and library designs that can take advantage of the
> generic types because the fluent design would no longer pass through
> the generic type and all operations would return ChronoLocalDate.

Users either use a specific type, or the abstract interface, they
won't tend to fix the two, A method:
<D extends CLD> D process(D date)
will work perfectly in both cases
 fooDate = process(fooDate)
 clDate = process(clDate)

The only thing "lost" is the ability to refer to one or more CLD
instances as being in the same calendar system, without specifying
which calendar system that is. This is no worse than j.u.Calendar
today, and in my view a rarer requirement.

> 2) Removing just the constraint on the extends clause doesn't solve the
> original problem and isn't an improvement of any significance.
>
> 3) The original symptom and difficulty of using the wildcard generic types
> from
> the API has a couple alternatives for work arounds.
> The application can itself use the raw types by casting or assignment of the
> return value to take advantage of the lenient type matching of raw types.
> The code compiles and runs correctly though the compiler produces
> warnings about raw type and unchecked assignments which can be suppressed
> selectively or in an appropriate scope.

No solution involving raw types on a public API would be acceptable to me,

> I would recommend against changing the type parameters; we're trying
> to freeze for the next build and integration.  The current parameter usage
> follows the general recommendations for generic types and the alternatives
> are not clear improvements on all points.  I'd like to get a bit more
> experience
> with the API before making changes.

So long as we can still make a change, its fine to leave it for now.

Stephen