wip-dcb-issue-89-jodatime. I just checked in everything I have, which means that branch currently doesn't compile. Maybe I'm overthinking it, but TimeHelpers does define some nice convenience methods and my goal is to replicate and extend that with Joda Time.
Derek On Mon, Oct 19, 2009 at 3:13 PM, David Pollak <feeder.of.the.be...@gmail.com > wrote: > What branch is the code on? > > > On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker > <dchenbec...@gmail.com>wrote: > >> 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 >>>> >>>> >>>> >> >> >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
