[threeten-dev] [threeten-develop] TemporalAdder and TemporalSubtractor

[Xueming Shen]

On 12/21/2012 09:35 AM, Stephen Colebourne wrote:
> On 21 December 2012 07:54, Xueming Shen<xueming.shen at oracle.com>  wrote:
> A TemporalPeriod concept is reasonable, however I don't think it
> removes the need for Adder/Subtractor.
>
> Consider the a balanced equivalence:
>
>   Temporal - defines the date-time type
>   TemporalAdjuster - deifnes how to make the adjustment
>
>   TemporalPeriod - defines the period type
>   TemporalAdder/Subtractor - defines how to add/subtract

While duration is one of the two fundamental elements (time and duration),
I would assume the "time" (date/time) is the main topic in this API, which is
Temporal in this mini framework, everything works on it and for it. The Adder
and Subtractor here  are not an exception, they try to help the plus and
minus operations on a Temporal.

What is Adder/Subtractor? If I understand the design correctly, it is something
that is supposed to know how to add a duration (machine time duration, human
time duration, known/existing duration or unknown type) to a known or unknown
type of date/time. The method name plus/minus has already provided enough
semantics information of WHAT should be done, it is

    temporal ± duration -> new temporal

And the HOW is clearly specified & implemented if the temporal and duration
on the left side are known/existing date/time and duration classes. What
needed here is SOMETHING that can help if  there is an unknow type, either
the temporal or the duration or both.

This is similar to other extensibility mechanism need in other places

with(field)
minus/plus(unit)

We add an general abstraction for field and unit, specify that the classes
that implement/extend those interface take the responsibility of handling
how to doWith and doMinus/Plus.

There is no difference here for the period case. The one that has the best
knowledge of how to add itself to a "temporal" is the period itself. Any
adder/subtracter has to know the period first and then to know how to
add/subtractor it to the temporal. Again, the equivalence here is

New Temporal = Old Temporal ± TemporalPeriod

One of the temporal and/or temporal period need to know how
to handle the plus/minus, if the TemporalPeriod is not one
of those existing duration/period classes, it should take
the responsibility of how to plus/minus it to a known
temporal. The existing approach is

New Temporal = Old Temporal ± Adder/Subtractor(TemporalPeriod)

what's the benefit of introducing a new layer of abstraction of
"adder" and "subtracter" here?

As I said, we have already have a general purpose "adjuster"
interface to make adjustment on a temporal already. plus and
minus is a special case of "adjustment", add/subtract 10 days
from a date/time is the same as "adjust" the date/time 10
days from the date/time or before date/time.

What we need here is NOT a mechanism of "HOW to add or minus a
SOMETHING from a Temporal" but how to provide the extensibility of
adding/subtracting a customized duration/period from a Temporal.

"HOW to add or minus a SOMETHING from a Temporal" is the same
as "HOW to ADJUST the Temporal by adding/minus SOMETHING", it's
a manipulation of those date/time fields inside the temporal to make
a new temporal, with a specific algorithm/rule. As I said in my previous
email, we don't need a second one.

How to define TemporalPeriod is not my point here, the methods I'm
adding in are to fit it for the minus/plus operation, as the TemporalField/
Unit interface does. We definitely add more "general" access method
into it, as you just suggested. Consider this, if we do introduce the
TemporalPeriod later, does that make the TemporalAdder/Subtractor a
redundant? at least for all the functionality it currently trying to provide?
then make the TemporalPeriod subclass of both Adder and Subtractor?

I would rather add a pure TemporalPeriod here for this purpose first,
with the hope that we can add more concrete methods (with default
implementation) later, if we are not sure what should be in for now.

Bottom line is why you need an extra Adder and Subtractor to stand
in the middle of Temporal = Temporal ± TemporalDuration, when
we have a clear definition of plus/minus, and we have two abstractions
clearly should/could know how to handle this well-defined operation.

-Sherman



> Currently, we don't have TemporalPeriod, primarily because we don't
> have period formatting (a useful thing for JDK9 maybe).
>
> Under this balanced equivalence approach, the TemporalPeriod would
> look something like this:
>
>   isSupported(Unit)
>   get(Unit)
>   getLong(Unit)
>
> ie, it would provide access to the unit-long map, not the
> addition/subtraction (which is what would be needed for a period
> formatter)
>
> By contrast, your chosen set of methods for TemporalPeriod are really
> an extended set from Adder/Subtractor, and would not fulfil the period
> formatter use case.
>
> Stephen