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

[roger riggs]

Hi Stephen,

There is time (at least a month) to consider this further and to make
changes as needed.

I would like to see some other folks experiences and I'll take a look at
some date/time libraries and conversions of existing code.

Thanks, Roger


On 4/5/2013 5:42 AM, Stephen Colebourne wrote:
> 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