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.



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