I'm going to try and implement both in the chronology (hop count and
base) by using two flags:
/**
* Finds the next or previous instant, starting from the input instant,
* where the field has the specified value.
* <p>
* The calculation is generally performed using a combination of a set
* followed by an add.
* If the value is invalid, an exception if thrown.
* <p>
* Finding the next match avoids changing other fields, especially
smaller
* sized ones. For exampe, finding the next 30th dayOfMonth after the
31st
* January will return the 30th March. The time fields will be
unaltered.
* <p>
* This method takes two arguments to control its behaviour. The first
* is the <code>numberOfRanges</code>, which can be positive or
negative.
* A positive value of one will find the first 'next' instant, whereas a
* value of three will find the third 'next' instant. Negative numbers
* work similarly but find 'previous' instants.
* <p>
* The second argument is <code>firstMustChange</code>, which controls
* whether the first 'next'/'previous' must be after/before the base
* instant or not. For example, consider the case where the base instant
* is the 1st of January and you request the next instant that the date
* is the 1st. Set this flag to true if you want the result to be the
* 1st of February, or false if you want the 1st of January. This flag
* only affects the finding of the first 'next'/'previous'.
*
* @param instant the milliseconds from 1970-01-01T00:00:00Z to set in
* @param value the value to set, in the units of the field
* @param numberOfRanges the number of ranges to move by, zero has
no effect
* @param firstMustChange whether the set must change the date
* @return the updated milliseconds
* @throws IllegalArgumentException if the value is invalid
*/
This can then be exposed by the property more simply.
Stephen
Brian O'Neill wrote:
>You might also including a "minimum hop count" parameter to advance by
>more than one. A value of zero would advance to Tuesday only if not
>already. One would advance always. Of course this does not cover cases
>like "advance three days, unless already Tuesday, in which case advance
>two".
>
>Stephen Colebourne wrote:
>
>
>>Hi all,
>>I am looking at adding next/previous setting behaviour to v1.3, but am
>>finding the exact naming strategy is tricky. This refers to the Property
>>classes on DateTime etc.
>>
>>The code being added allows you to take a base date and set a value (ike
>>setCopy) but forcing it tobe in the future. An example use isto get the
>>date of next Tuesday, or the first of next month.
>>
>>DateTime nextTue = dt.dayOfWeek().next(DateTimeConstants.TUESDAY);
>>DateTime firstOfNextMonth = dt.dayOfMonth().next(1);
>>
>>Unfortunately, this isn't a simple one new method: Given a date, does
>>'next Tuesday' mean that the date must be later than the start point or
>>not? ie. if you request 'next Tuesday' on a date that is already a
>>Tuesday should you move later or not? Both are valid business use cases.
>>
>>Here as some possible method names:
>>
>>Use method names - difficult to explain in the name:
>> dt.dayOfWeek().withNext(TUESDAY); - nop if dt is Tue
>> dt.dayOfWeek().withNextAfter(TUESDAY); - must be after dt
>>or
>> dt.dayOfWeek().withNextValueThisOrLater(TUESDAY); - nop if dt is Tue
>> dt.dayOfWeek().withNextValueLater(TUESDAY); - must be after dt
>>or
>> dt.dayOfWeek().withValuePushingLater(TUESDAY); - nop if dt is Tue
>> dt.dayOfWeek().withNext(TUESDAY); - must be after dt
>>or
>> dt.dayOfWeek().withNextAllowCurrent(TUESDAY); - nop if dt is Tue
>> dt.dayOfWeek().withNext(TUESDAY); - must be after dt
>>
>>Use a flag - 'must be later':
>> dt.dayOfWeek().withNext(TUESDAY, true);
>>or
>> dt.dayOfWeek().withNextValue(TUESDAY, true);
>>
>>Ignore the problem - client code must write an if statement:
>> dt.dayOfWeek().withNext(TUESDAY);
>>or
>> dt.dayOfWeek().withNextValue(TUESDAY);
>>
>>
>>I'm not sure which I prefer. I like short names, and the with prefix is
>>a given. The withValuePushingLater/withNext combination is probably the
>>most expressive, but 'pushing' is pretty yucky. I really dislike boolean
>>flags, so I'd prefer to not do that, and leaving it to the client code
>>seems to miss the point.
>>
>>(Bear in mind that the correct name for setCopy is withValue)
>>
>>But if you've any other ideas of method names, let us know.
>>
>>Stephen
>>
>>
>>_______________________________________________
>>Joda-interest mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/joda-interest
>>
>>
>>
>>
>
>
>_______________________________________________
>Joda-interest mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
>
_______________________________________________
Joda-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/joda-interest
