[threeten-dev] TzdbZoneRulesCompiler

[Xueming Shen]

On 12/14/12 3:30 PM, Stephen Colebourne wrote:
> On 14 December 2012 23:25, Xueming Shen <xueming.shen at oracle.com> wrote:
>> On 12/14/12 2:56 PM, Stephen Colebourne wrote:
>>> Taking a step back, I think that ZoneRules probably does not need to
>>> be an interface. There are only two sensible implementations - single
>>> offset and complex, as per StandardZoneRules.
>>
>> One benefit of having ZoneRules to be interface is that other implementation
>> does
>> not have to have their implementation bundled with the existing
>> implementation.
>> I was hoping we can get rid of the ZOTR as well, since it's kinda specific
>> to how the
>> tzdb is defined. But if other implementation will have to deal with ZOT and
>> ZOTR
>> anyway, it might not be too bad that they have to build the rule based on
>> the
>> specified constructor/factory method (I'm sure you want to make sure the
>> class
>> ZoneRules to be final as well).
> With ZOT and ZOTR public with factory methods,it makes sense to have
> ZoneRules also final. It certainly means that they more clearly
> justify their place in the API.

I'm OK with the change.

Btw, is TzdbZoneRuleProvider public by purpose? or just an accident. I don't
think this one need to be public.

-Sherman


>
> It also turns out that the internal implementation of
> StandardZoneRules is complex, and I don't really want others
> replicating that. So, I find lots of arguments for a class-based
> ZoneRules and not many for the interface.
>
> Stephen
>
>
>> Yes, have a concrete ZoneRules with public create and access methods
>> definitely
>> make the life of the compiler tool easier.
>>
>> -Sherman
>>
>>> If we made this change, then StandardZoneRules and the rules inside
>>> ZoneOffset would merge inside ZoneRules. Then, all the serialization
>>> would stay in the core. The tool would simply create the necessary
>>> items to pass to the standard public factory on ZoneRules.
>>>
>>> So, what you've done makes sense given where we are, but I think there
>>> is a better option.
>>>
>>>
>>
>>