I spoke too soon. If I try to do masking imports, I get errors about ambiguous defs:
[WARNING] /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71: error: reference to now is ambiguous; [WARNING] it is imported twice in the same scope by [WARNING] import _root_.net.liftweb.util.JodaTimeHelpers._ [WARNING] and import _root_.net.liftweb.util.TimeHelpers._ [WARNING] 3.seconds.later.millis must beCloseTo((now + 3.seconds).millis, 100L) Since TimeHelpers is automatically part of Helpers, and "import Helpers._" is a pretty common import, it's going to require some other mechanism to get the proper import into scope. Any solution which results in "now" returning a java.util.Date essentially defeats the purpose of moving to Joda Time, since you can just do /** transforms a java.util.Date to a org.joda.time.DateTime */ implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in) /** transforms an org.joda.time.DateTime to a java.util.Date */ implicit def dateTimeToDate(in : DateTime) : Date = in.toDate in your code and get most of it for free. What I'm trying to achieve here is a refactoring of Lift's time formatting and processing API that lends itself to clean usage of JodaTime. Derek On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker <dchenbec...@gmail.com>wrote: > 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 -~----------~----~----~----~------~----~------~--~---
