Well, yes. I actually had similar code working, but what I was trying to avoid is a situation where someone has code like:
import Helpers._ .. val someTime = now + ( 3 minutes) and then to use this code with JodaTime they need to change it to val someTime = jtNow + (3 minutes) and then when we remove the current java.util impl they would have to switch back to the original code. Also, because of all of these issues I haven't fully worked out things like JodaSpanBuilder, which should really be using JodaTime's Periods instead of Durations since those take into account things like daylight savings time and leap years (none of the current code does that right now, java.util or JodaTime). If this is the best compromise we can come up with I'll just make a new branch to finish working on the JodaTime side of things. Thanks, Derek On Mon, Oct 19, 2009 at 4:57 PM, David Pollak <feeder.of.the.be...@gmail.com > wrote: > Please take a look at > http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7 > > I think I've got JodaTime and the existing code playing nicely together. > > > On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker > <dchenbec...@gmail.com>wrote: > >> 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 >>> >>> >>> >> >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
