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

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