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

[roger riggs]

Prompted by the issue #292 ChronoLocalDate generics difficult to use 
<https://github.com/ThreeTen/threeten/issues/292>
I followed up on the suggestions and did some prototyping of 
alternatives to
the generics on  ChronoLocalDate<D extends ChronoLocalDate<D>>.

The ChronoZonedDateTime and ChronoLocalDateTime types parameter
remains <D extends ChronoLocalDate<D>> since they retain references
the date and can return the parameterized type.

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.

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.

One alternative to the wildcard return types is to return the raw 
ChronoLocalDate.
In the example, the raw type does not produce a compilation error but does
cause the unchecked cast warning.

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.

Roger