The major issue is the time DSL. Everything else works fine by masking the definitions with a later import, e.g.
import Helpers._ import JodaTimeHelpers._ The problem is that implicit defs (views) don't mask, so I can't override or mask it so that "3 seconds" returns a Joda Time Duration, which is a cleaner way of representing time durations in milliseconds. In order to get a better discussion going, I'll go ahead and comment out my refactored DSL and put up the code that does work this afternoon and we can discuss it from there. Derek On Mon, Oct 19, 2009 at 1:37 PM, David Pollak <feeder.of.the.be...@gmail.com > wrote: > 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 -~----------~----~----~----~------~----~------~--~---
