[threeten-dev] Review fix for periodUntil issue 273

[Stephen Colebourne]

I would not have added the check to ensure a 12 month year (I'd just
rely on Javadoc rather than slowing user code).

Personally, I'd like to see the use of "public abstract" on all
methods in interfaces where there is at least one "default" ("public
default") method. This should be adopted as a new coding standard by
Oracle in the light of the trait-like design of default methods in
interfaces.

thanks
Stephen



On 1 March 2013 22:56, roger riggs <roger.riggs at oracle.com> wrote:
> Revised the webrev:
>
> http://cr.openjdk.java.net/~rriggs/webrev-fix-perioduntil-273/
>
> Thanks, Roger
>
>
> On 3/1/2013 2:40 PM, Xueming Shen wrote:
>>
>> while we are on this, it appears two ChronoLocalDate.periodUntil() methods
>> are declared as "public abstract ...", any particular reason to do that?
>> or just
>> a "leftover" of the previous life of CLD as an abstract class, instead of
>> an interface
>> now?
>>
>> On 03/01/2013 10:25 AM, Xueming Shen wrote:
>>>
>>>
>>> On 3/1/13 9:41 AM, Xueming Shen wrote:
>>>>
>>>> -ChronoDateImple.periodUntil(t, u)
>>>>   The "convention" is to align the "case" to the "switch" in jdk source
>>>> code?
>>>>
>>>> - Understood it is kinda of 310 convention to have "... == false", but I
>>>> would suggest to
>>>>    use the the normal (! X) instead.
>>>>
>>>> -ChronoLocalDate.periodUntil(CLD) says the "calculation is performed
>>>> using the chronology
>>>>   of this date. If necessary, the input date will be converted to match"
>>>> (btw, there are two
>>>>   "the"s here), but all our 4 jdk-provided ChronoLocalDate only handle
>>>> "same type" of CLD
>>>
>>>
>>> I meant to say 3.
>>>
>>>
>>>>   now,  (their java doc currently simply is inherited from the super
>>>> class). Is it possible to have
>>>>   a better alternative? at least they all have a isodate.
>>>>
>>>> -Sherman
>>>>
>