Re: [threeten-develop] Filling the gaps in the Calendar Neutral API
Status: Alpha
Brought to you by:
scolebourne
Menu
▾
▴
Re: [threeten-develop] Filling the gaps in the Calendar Neutral API
|
From: Benjamin G. <ben...@gm...> - 2012-05-23 19:25:35
|
Hi Roger,
I give your example a try but if I read correct is a simple case of delegation,
and subclassing.
class MyDate extends ChronoDate {
final ChronoDate date;
:-)
THX
Benjamin
On 23.05.2012 20:38, Roger Riggs wrote:
> HI Benjamin,
>
> Thanks for the use case. If I understand, this is a simple case of
> delegation, not subclassing.
>
> In the case of ISO, the javax.time.LocalDate class is public and visible and
> you can use its factory methods, such as LocalDate.of(y,m,d) directly;
> embedding a reference. When a new date is computed, the new date gets
> wrapped in a new instance of your new subtype of ChronoDate.
>
> Delegation to another calendar is about the same; the reference to the ChronoDate
> instance initially comes from a lookup of the needed Chrono instance and
> using its Chrono.date(y,m,d) method as the factory for a ChronoDate. After that
> most operations are performed on the ChronoDate and its methods produce
> new instances of the same type; which will need to be encapsulated in a new
> instance of your date type. If you need to go back to the Chono to create a new
> date the Chrono.date(y,m,d) factory method is used.
>
> For example, a fragment.
>
> class MyDate extends ChronoDate {
> final ChronoDate date;
>
> public static MyDate of(int y, int m, int d) {
> return of(ChronoDate.getByName("ISO").date(y,m,d));
> }
> private static MyDate of(ChronoDate date) {
> this.date = date;
> }
>
> public MyDate nextHoliday() {
>
> ChronoDate newDate = ... ; // Figure out next holiday after date
> if (newDate == date)
> return this;
> return of(newDate);
> }
>
> public int getDayOfMonth() {
> return date.getDayOfMonth();
> }
> ...
>
> }
>
>
> Roger
>
>
>
> On 05/23/2012 02:05 PM, Benjamin Graf wrote:
>> Hi Roger,
>>
>> I'm not convinced, yet. Maybe it helps if I explain you a use case I'm
>> actually working at.
>>
>> I build an ISO based business calendar on top of the actual Chrone API. It
>> has a factory for one locale handling and implementation handling of
>> different holiday rule configurations (e.g. file or database based). Since I
>> do not want to implement the whole abstract methods twice I directly call
>> ISOChrono.INSTANCE.xxx to get the similar result (embedded in my own
>> BusinessDate object). It is also very important for me to be allowed to
>> enhance the Date objects extending ChronoDate to create a wider API with
>> methods like isHoliday or isWorkday. I actually see difficulties to implement
>> seeing that the Chrono POC tend into a more closed direction.
>>
>> Understandable? :-)
>>
>> Benjamin
>>
>> On 22.05.2012 22:33, Roger Riggs wrote:
>>> Hi Benjamin,
>>>
>>> On 05/22/2012 02:41 PM, Benjamin Graf wrote:
>>>> I don't think it is a good idea to encapsulate the Chrono implementations
>>>> behind a factory for three reasons.
>>>> 1.) How would you guarantee extendability or do you think you meet all
>>>> necessary implementations?
>>> The POC was mostly targeted around the enums for day-of-week, month-of-year,
>>> and eras
>>> and simplification.
>>> Extensibility is a goal and is achieved by providing additional implementations
>>> of the Chrono class and enable the discovery mechanism used by getByLocale,
>>> getByName to find them by name and locale. Details forthcoming.
>>>
>>>> 2.) Why do you pretend to hide Chrono implementations like ISOChrono? It
>>>> might be a good usecase to compose a new chrono around the ISO ones!
>>> My observation of the previous API was that there was little value in the
>>> exposing
>>> the Java Type of the chronology. Since the purpose of the Calendar Neutral API
>>> was to make it possible to select the calendar as a parameter without
>>> hardcoding the type.
>>> Exposing the Java type detracted from the premise of the Chrono API.
>>>
>>> A new Chronology can be implemented in way suitable for the calendar.
>>> A new calendar would define new Chrono subtype and it is the factory for
>>> the subtype of ChronoDate. Look at the current implementation of Coptic and
>>> Minguo
>>> for some of the available implementation techniques.
>>>
>>>> 3.) Chrono.getByName(name) -> Typesafety???
>>> The compile time and type specific guarantees of ChronoDate are deliberately
>>> weaker than those for LocalDate to enable the API to be used with different
>>> calendars.
>>> The ChronoDate class doesn't specify how many months in a year or eras.
>>> The user of the api must take into account they may vary. But the months are
>>> named and specific to the calendar and the API can use them to discover
>>> the available Eras, etc.
>>>>
>>>> If you like to tend to a Locale focused factory you have to think about an
>>>> plugin infrastructure to allow people to use it the way they like.
>>>> Otherwise I think acceptance won't be rising that much!
>>> See the next email for extensibility to add Calendars, Richard has the same
>>> concern.
>>>
>>> Thanks, Roger
>>>
>>>>
>>>> Benjamin
>>>>
>>>> On 21.05.2012 21:49, Roger Riggs wrote:
>>>>> To make the ChronoDate API meet the requirements a few gaps need
>>>>> to be filled and a few outstanding problems need solutions.
>>>>>
>>>>> See the javadoc for the developer view:
>>>>> http://cr.openjdk.java.net/~rriggs/threeten-chrono/javax/time/chrono/package-summary.html
>>>>>
>>>>>
>>>>> To be able to create a ChronoDate the application can choose a default based
>>>>> on locale or can list of the available calendars from the Chrono.getNames
>>>>> method.
>>>>> The static methods Chrono.getByLocale(locale) or Chrono.getByName(name)
>>>>> are used to get the appropriate Chrono instance. Its methods are used to
>>>>> create
>>>>> dates, as in chrono.date(era, year, month, day) or chrono.now();
>>>>>
>>>>> Chrono chrono = Chrono.getByLocale(locale);
>>>>> ChronoDate now = chrono.now();
>>>>> int year = now.getProlepticYear();
>>>>> int day = now.getDayOfMonth();
>>>>>
>>>>> For months, each Calendar provides a sequence of months appropriate
>>>>> to that calendar. For some calendars and years there are 12 months and
>>>>> in others 13. From each month the methods support access to the other
>>>>> months as first(), last(), plus(n), etc. Each MonthOfYear has its index
>>>>> and label.
>>>>> The months can vary from year to year as needed in a few calendars.
>>>>> (NB: For the POC, this MonthOfYear is different than the ISO MonthOfYear).
>>>>>
>>>>> MonthOfYear first = chrono.getMonthsOfYear().first();
>>>>> MonthOfYear last = first.last(); // last month of the year
>>>>> int nmonths = first.length(); // number of months in the year
>>>>>
>>>>> MonthOfYear thismonth = now.getMonthOfYear();
>>>>> String name = thismonth.label(); // label for current month
>>>>>
>>>>> ChronoDate lastmonth = now.withMonthOfYear(last);
>>>>> ChronoDate lastdayofyear =
>>>>> lastmonth.withDayOfMonth(lastmonth.lastDayOfMonth());
>>>>>
>>>>> This form of enumeration is applicable to any sequence including Months,
>>>>> Eras,
>>>>> and days of weeks. It can be applied to ISO and non-ISO calendars.
>>>>>
>>>>> The calendar neutral API operates on a calendar without compiling
>>>>> any calendar specific types into the code. The generics on Chrono and
>>>>> ChronoDate
>>>>> are removed since they were not necessary; the API does not rely only any
>>>>> calendar specific types. The use of the enumerations for months, eras,
>>>>> and weekdays
>>>>> avoids the proliferation of calendar specific types while still providing
>>>>> accurate
>>>>> sequences of months, and era information to the application.
>>>>>
>>>>> This proof of concept shows an alternate enumeration suitable for
>>>>> variable numbers of months and eras and a simple calendar neutral API
>>>>> can be functional and usable.
>>>>>
>>>>> More tuning is needed if the concepts are useful.
>>>>>
>>>>> Roger
>>>>>
>>>>>
>>>>> For those curious about the implementation the diffs may be useful.
>>>>> http://cr.openjdk.java.net/~rriggs/threeten-chrono/chrono.diff
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> threeten-develop mailing list
>>>>> thr...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>
>>>
>>> _______________________________________________
>>> threeten-develop mailing list
>>> thr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop
>
>
|