Or, if you're OK with it, I could just make a lift-joda module that has the
traits. That would also keep the Joda Time dependency out of the main lift

On Tue, Oct 20, 2009 at 5:48 PM, 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

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