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 
For more options, visit this group at 

Reply via email to