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

[Xueming Shen]

On 12/27/2012 9:53 AM, Stephen Colebourne wrote:
> On 21 December 2012 20:27, Xueming Shen<xueming.shen at oracle.com>  wrote:
>> 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?
> Were there to be a TemporalPeriod (since it isn't a temporal, it
> should really be called something else, like Perioral), then it would
> not extend Adder/Subtractor. However, all *implementations* would
> extend TemporalPeriod, Adder and Subtractor.
>
> This is exactly the same as how LocalDate extends both Temporal and
> TemporalAdjuster, but Temporal and TemporalAdjuster are independent of
> one another. Different layers for different purposes.
>
>> 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 defintion of plus/minus, and we have two abstractions
>> clearly should/could know how to handle this well-defined operation.
> There are other possible classes that might wish to only implement
> adder/subtractor, and not be an entire period. The example in the
> javadoc is a method returning business/working days
>
>   date.plus(workingDays(6));
>
> The concept of "6 working days" is not a period, but it is a mechanism
> of addition. That is why Adder is different to the currently
> non-existing TemporalPeriod.
>

date.plus(workingDays(6)) cat be perfectly implemented as
date.with(workingDaysAfter(6)), with the temporalAdjuster interface. The name
might not be perfect, but I don't think it's a big concern.

If you take a step back and look at these interfaces again,

Temporal.plus(TemporalAdder) + TemporalAdder
Temporal.minus(TemporalSubtractor) + TemporalSubtractor
Temporal.with(TemporalAdjuster) + TemporalAdjuster

are three exactly the same mechanisms, the only difference is the "wording"
(even the wordings are similar), with the TemporalAdjuster as the most "general
purpose" interface, by its name.

What I'm questioning here is exactly the "different layers for different purposes"
design on a simple abstraction. Do we really need two/three layers of abstraction
here for "different purpose"? While to provide two more specific add & minus
adjustment interfaces may bring some benefits, but it also adds the complicity
to the interface, developers will have to deal with three different abstractions
and different interfaces and have to figure out which one is "best" for what,
while the reality is these three are exactly the same. We are talking about a
"base" interface with 7 methods, and 3 of them are the "same thing" (again,
they are just the "adjustment", one general, two specific).

Let me try it again.

time = time +/- duration   -> temporal = temporal +/- temporalduratin(perioral?)

temporal = temporal +/- tempralAddor/Subtractor(perioral)

simply makes thing complicated with an extra layer, it'd be better leave those
"addor/subtractor" to the adjuster.

-Sherman