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 modules.
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 liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
