[threeten-dev] some questions for with() method in java.time.chrono.ChronoLocalDate

[roger riggs]

Hi Patrick,

On 7/12/2013 6:23 AM, Patrick Zhang wrote:
> Hi Team,
>
> I am reading source code of threeten project and find something 
> strange in java.time.chrono.ChronoLocalDate.
> There are 2 with() methods, mostly I am confused by below:
> ======
>     default ChronoLocalDate with(TemporalField field, long newValue) {
>         if (field instanceof ChronoField) {
>             throw new UnsupportedTemporalTypeException("Unsupported 
> field: " + field);
>         }
>         return ChronoDateImpl.ensureValid(getChronology(), 
> field.adjustInto(this, newValue));
>     }
>
> ======
>
> As you know, ChronoLocalDate with(TemporalField field, long newValue) 
> is not DEFAULT in ChronoLocalDateTime and ChronoZonedDateTime.
>
> 1. Why we make it as default in ChronoLocalDate?
This is a defensive strategy to make sure implementations of 
with(TemporalField field, value)
for built-in fields (ChronoField) are handled in the concrete 
implementations.
If a concrete implementation failed to override the method it throws the 
exception.

For other subtypes of TemporalField it delegates to the field to
figure out how to compute the value and produce the updated date
in terms of the intrinsic fields (month, day, hour, etc) using some 
combination
of ChronoFields.

If it did not throw the exception, it would recursively call the 
field.adjustInto which
would call the temporal.with() which would call field.adjustInto()... 
til the stack was
consumed.

Since it is expected that additional Chronologies will add subclasses
of ChronoLocalDate (and not all by Oracle) the default method
is a precaution to catch early mistakes in coding.


> 2. The implement looks strange. Why it does not support standard 
> ChronoField and must throw UnsupportedTemporalTypeException explicitly?
>
Every concrete Subclass must override the method and compute the new value.

The interfaces ChronoLocalDateTime and ChronoZonedDateTime
as just holders of a time, date, etc and delegate to the date or time as
appropriate.  Perhaps it could have been implemented as a "default" method
but since it is expected there is only a single 'final' implementation
of each it the default method would not be needed/useful.

Roger


> Regards
> Patrick
>