[threeten-dev] Review fix for periodUntil issue 273

[Xueming Shen]

(3) ChronoLocalDate#535 and #540 are redundant, Ln#535 probably can be just removed.
       Same as the wording in LocalDate.periodUntil(CLD).

On 03/01/2013 03:37 PM, Xueming Shen wrote:
>
> (1) "public" is also not needed for interface method
> (2) ChronoDateImpl#332:
>      LocalDate.periodUntil() has requirenonNull(endDate...) before throwing DTE, to be consistent?
>
> otherwise looks fine.
>
> On 03/01/2013 02:56 PM, roger riggs 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
>>>>>
>