I've just looked at the code. There's nothing that's going to be incompatible moving to JodaTime. Sure, the month method will have a different result if you pass it a JodaTime instance than in you pass it a Date instance. If this is documented, then it's not a problem.
Existing methods don't get changed. For methods that return a Date or Calendar, there'll be a parallel method (e.g., jNow or somesuch) that returns a JodaTime instance. Existing methods that take a Date or Calendar, there'll be parallel methods that take a JodaTime instance. Where does this seem unworkable? On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen <je...@ingolfs.dk>wrote: > > Derek Chen-Becker <dchenbec...@gmail.com> writes: > > > That's pretty much my take. The whole Java Calendar/Date/Timezone impl is > > poorly designed, hence Joda Time. > > > > Now I've run into another wall, this time with the TimeSpanBuilder. I > can't > > mask the implicits from long/int to TimeSpanBuilder, so I can't define > the > > same DSL for things like "3 seconds", etc. I tried to provide an implicit > > conversion from TimeSpan to JodaSpan but that won't cover all of the > cases > > and this is feeling increasingly ugly as I add more and more layers and > > implicit defs to work around the old API. > > I haven't looked very closely at the current code, so don't really know > what the issues are..... but this won't stop me from commenting. I'm > really looking forward to get rid of Calendar and friends.... > > > At this point, the only way that this may work is if I create and > entirely > > new JodaHelpers object that extends all of the Helpers traits, replacing > > TimeHelpers with my new JodaTimeHelpers trait. This may be the path of > least > > pain, but it means two cycles of deprecation: one to deprecate the > current > > TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate > > JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this > sound > > like a reasonable approach, or is this getting too crazy? > > Depending on the cycle-length, this doesn't sound too bad. But if it is > 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already > has numerous breaking changes so if a cycle is just a milestone release > then I think it's fine. > > > The other option I thought of is to make a new branch just for this and > > just track master with the branch. The big downside is that this doubles > the > > release work to have a Joda Lift and non-Joda Lift. > > Doesn't sound like a viable approach. We'll be carrying this baggage > forever (unless this was only a temp solution?) > > /Jeppe > > > > > -- 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 liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
