Period is field-based, and therefore deals with non-linear time changes like
daylight savings time. Periods can be converted to millisecond durations
based on "standard" field durations (60 seconds == 1 minute, etc) if needed,
so it's a superset of the current functionality of TimeSpan.

On Fri, Oct 23, 2009 at 3:37 PM, David Pollak <feeder.of.the.be...@gmail.com
> wrote:

>
>
> On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker 
> <dchenbec...@gmail.com>wrote:
>
>> Well, I had intended to write a JodaHelpers trait that is the same as
>> Helpers except with JodaTimeHelpers and JodaTimeFormats replacing
>> TimeHelpers and TimeFormats, respectively. The main reason is that I would
>> like to have the time DSL be based on Periods instead of millisecond
>> durations, and with TimeHelpers already in scope there would be ambiguous
>> implicit conversions from Long/Int to TimeSpan or Period.
>
>
> What is the advantage of using Period internally instead of milliseconds?
>
>
>> Supposedly, 2.8 will have some support for masking or overriding
>> implicits, but I don't want to rely on that in the short term. If a
>> JodaHelpers trait that would replace a Helpers import isn't OK then I can
>> just do this in my own repo.
>>
>> Thanks,
>>
>> Derek
>>
>>
>> On Fri, Oct 23, 2009 at 2:52 PM, David Pollak <
>> feeder.of.the.be...@gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker <
>>> dchenbec...@gmail.com> wrote:
>>>
>>>> It sounds like you're pretty set against making separate impl traits and
>>>> would prefer just putting things directly on TimeHelper. I'm OK with that,
>>>> but I would really like to add a lift-joda module that contains the
>>>> JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to
>>>> use them. I should be able to delegate a good chunk of the methods to
>>>> TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a
>>>> reasonable compromise?
>>>>
>>>
>>> Yes, as long as import Helpers._ is not incompatible with importing
>>> whatever trait you come up with.
>>>
>>>
>>>>
>>>> Derek
>>>>
>>>>
>>>> On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker <
>>>> dchenbec...@gmail.com> wrote:
>>>>
>>>>> I agree that the goal isn't to remove java.util.Date. For trivial time
>>>>> handling it works just fine. What I'm trying to achieve here is a way to
>>>>> make Joda Time be the default impl while leaving the user a choice. By 
>>>>> using
>>>>> separate traits instead of different names on the same trait, we achieve a
>>>>> few things:
>>>>>
>>>>>    1. A consistent API for both java.util and Joda Time in terms of
>>>>>    method names. As Naftoli pointed out, people expect naming of functions
>>>>>    consistent with what they do and having two different "now"s on the 
>>>>> same
>>>>>    trait is going to look a little strange to people, I think.
>>>>>    2. A clean *optional* usage of Joda Time. If we put code that
>>>>>    utilizes Joda Time directly into TimeHelpers then it's not an optional
>>>>>    dependency. Making a separate trait means that if someone doesn't use 
>>>>> the
>>>>>    Joda Time trait then they don't need to have the Joda Time jar in their
>>>>>    classpath and they never know that it's not there.
>>>>>    3. A relatively simple code change path to move from java.util to
>>>>>    Joda Time by simply changing imports.
>>>>>
>>>>> Your assertion that Date is a simple wrapper for a Long timestamp is
>>>>> pretty accurate, but really Joda Time's DateTime is a superset of
>>>>> *Calendar*, not Date. Just look at what we had to do with 
>>>>> CalendarExtension
>>>>> to get some simple date manipulation functions, where those same methods 
>>>>> are
>>>>> already defined on DateTime. The vast majority of Joda Time's classes are
>>>>> immutable, and the mutators return new instances instead of modifying the
>>>>> current instance. TimeSpan's current handling of duration addition doesn't
>>>>> cope with DST, which I'm sure will show up as a bug in someone's code if 
>>>>> it
>>>>> hasn't already. Having done a fair amount of java.util.Date handling and
>>>>> then moving to Joda Time, I find it hard to call the difference between 
>>>>> the
>>>>> two APIs "marginal". In any case, I still feel that my proposal makes Joda
>>>>> Time available in a nicer way while leaving existing code completely
>>>>> untouched (by introducing a JodaHelpers trait that mirrors Helpers).
>>>>>
>>>>> Derek
>>>>>
>>>>>
>>>>> On Tue, Oct 20, 2009 at 9:25 PM, David Pollak <
>>>>> feeder.of.the.be...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim <
>>>>>> naftoli...@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> I agree with this.
>>>>>>> My understanding is that the goal is that Lift should use Joda for
>>>>>>> its time functions rather than java.util.
>>>>>>
>>>>>>
>>>>>> This is not the goal.  The goal is to make JodeTime available.  There
>>>>>> is no reason to remove support for java.util.Date.  None.
>>>>>>
>>>>>> JodaTime offers some advantages, but there's no reason, none, nada, to
>>>>>> *remove* support for java.util.Date.
>>>>>>
>>>>>> I'm cool with different names (not jtNow, but choose something else).
>>>>>>
>>>>>> But I view removal of support for java.util.Date as gratuitous.  Sure,
>>>>>> if we were to make the clean-slate decision today, I'd opt for primary
>>>>>> support of JodaTime and secondary support for java.util.Date.  But we're
>>>>>> making a decision based on legacy.  We're not going to cut off
>>>>>> java.util.Date just because something marginally better (and I'm not
>>>>>> being facetious here... at the bottom, these are just wrappers for 
>>>>>> number of
>>>>>> milliseconds since Jan 1, 1970).
>>>>>>
>>>>>>
>>>>>>> If the Joda methods have different and longer names, then it's
>>>>>>> existing side by side with the java.util implementation, not replacing 
>>>>>>> it.
>>>>>>> To many people, it is important that methods etc. should be named
>>>>>>> properly and aesthetically. It's not pleasant to use names like "jtNow" 
>>>>>>> in
>>>>>>> your code when that is the method that gets used normally. Sure, if 
>>>>>>> 'now'
>>>>>>> was the usual method and a 'jtNow' method was called in special
>>>>>>> circumstances, it's an understandable name. But names that are used in
>>>>>>> ordinary circumstances should have straightforward names.
>>>>>>> (Names should be concise expressions of what they represent. This
>>>>>>> aids in memorization and code readability.)
>>>>>>> Also, it will be impossible to deprecate the java.util implementation
>>>>>>> and have a clean API instead. If we use separate traits with the same 
>>>>>>> method
>>>>>>> names, then we will be able to.
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------
>>>>>>> Derek Chen-Becker<dchenbec...@gmail.com> wrote:
>>>>>>>
>>>>>>> On Tue, Oct 20, 2009 at 4:59 PM, David Pollak <
>>>>>>> feeder.of.the.be...@gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>> > What I checked in allows you to use JodaTime just as easily (well
>>>>>>> with 2
>>>>>>> > extra characters in a few method names) as java.util.Date.  How is
>>>>>>> anything
>>>>>>> > more "default" than that?
>>>>>>> >
>>>>>>>
>>>>>>> My primary concern with this approach is that it makes changing
>>>>>>> between the
>>>>>>> two implementations something that requires a global search and
>>>>>>> replace on
>>>>>>> one or more method names, whereas having two different implementation
>>>>>>> traits
>>>>>>> means that generally I should be able to just change the import and
>>>>>>> the code
>>>>>>> will work. A secondary (minor) concern is that having method names
>>>>>>> reflect
>>>>>>> the underlying implementation details goes against my aesthetics.
>>>>>>>
>>>>>>>
>>>>>>> > It's an interesting difference between an OO vs. non-OO.  In the
>>>>>>> > implementation I created, there choice of one or the other is made
>>>>>>> based on
>>>>>>> > singleton methods invoked.  This allows mixing both in the same
>>>>>>> code simply
>>>>>>> > by invoking now or jtNow.
>>>>>>> >
>>>>>>>
>>>>>>> I would argue that it's not a common case where you would want to use
>>>>>>> both
>>>>>>> libraries, particularly when Joda's DateTime has an explicit toDate
>>>>>>> on it
>>>>>>> that returns a java.util.Date. There are similar methods to return
>>>>>>> Calendar
>>>>>>> and TimeZone instances as needed. These are simple methods to use
>>>>>>> directly,
>>>>>>> or it's easy to create a view that handles this automatically.
>>>>>>>
>>>>>>> I'm unclear why this is not possible.  We can add a DSL for
>>>>>>> manipulating
>>>>>>> > JodaTime without breaking anything we have.  The TimeSpan class
>>>>>>> simply gets
>>>>>>> > enhanced to deal with additional stuff and maybe uses JodaTime
>>>>>>> under the
>>>>>>> > covers.
>>>>>>> >
>>>>>>>
>>>>>>> The underpinning of the current DSL is the TimeSpan class. Joda Time
>>>>>>> already
>>>>>>> has a time interval class corresponding to TimeSpan called Duration,
>>>>>>> but the
>>>>>>> more proper class to use is actually Period. Period is premised not
>>>>>>> on ms
>>>>>>> duration but rather on field deltas, which allows it to properly
>>>>>>> handle DST.
>>>>>>> Modifying the current DSL to work for Duration and Period via
>>>>>>> TimeSpan is
>>>>>>> just going to end up with a lot of redundant code, when a Joda-only
>>>>>>> DSL
>>>>>>> would be cleaner and more in line with how you would want to use Joda
>>>>>>> Time.
>>>>>>>
>>>>>>>
>>>>>>> > They have that now with the implementation I did on your branch.
>>>>>>> >
>>>>>>>
>>>>>>> Like I said before, I have a strong preference for the OO approach
>>>>>>> and being
>>>>>>> able to change impls by changing the import rather than having to
>>>>>>> change
>>>>>>> methods all over the place. If you really feel strongly that we can't
>>>>>>> have a
>>>>>>> separate trait in Lift, I can just create a different artifact in my
>>>>>>> own
>>>>>>> repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and
>>>>>>> JodaTimeHelpers traits there.
>>>>>>>
>>>>>>> Cheers,
>>>>>>>
>>>>>>> Derek
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lift, the simply functional web framework http://liftweb.net
>>>>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>>>>> Follow me: http://twitter.com/dpp
>>>>>> Surf the harmonics
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Lift, the simply functional web framework http://liftweb.net
>>> Beginning Scala http://www.apress.com/book/view/1430219890
>>> Follow me: http://twitter.com/dpp
>>> Surf the harmonics
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to