Period is field-based, and therefore deals with non-linear time changes like daylight savings time. Periods can be converted to millisecond durations based on "standard" field durations (60 seconds == 1 minute, etc) if needed, so it's a superset of the current functionality of TimeSpan.
On Fri, Oct 23, 2009 at 3:37 PM, David Pollak <feeder.of.the.be...@gmail.com > wrote: > > > On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker > <dchenbec...@gmail.com>wrote: > >> Well, I had intended to write a JodaHelpers trait that is the same as >> Helpers except with JodaTimeHelpers and JodaTimeFormats replacing >> TimeHelpers and TimeFormats, respectively. The main reason is that I would >> like to have the time DSL be based on Periods instead of millisecond >> durations, and with TimeHelpers already in scope there would be ambiguous >> implicit conversions from Long/Int to TimeSpan or Period. > > > What is the advantage of using Period internally instead of milliseconds? > > >> Supposedly, 2.8 will have some support for masking or overriding >> implicits, but I don't want to rely on that in the short term. If a >> JodaHelpers trait that would replace a Helpers import isn't OK then I can >> just do this in my own repo. >> >> Thanks, >> >> Derek >> >> >> On Fri, Oct 23, 2009 at 2:52 PM, David Pollak < >> feeder.of.the.be...@gmail.com> wrote: >> >>> >>> >>> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker < >>> dchenbec...@gmail.com> wrote: >>> >>>> It sounds like you're pretty set against making separate impl traits and >>>> would prefer just putting things directly on TimeHelper. I'm OK with that, >>>> but I would really like to add a lift-joda module that contains the >>>> JodaHelpers, JodaTimeFormats and JodaTimeHelpers traits as I would like to >>>> use them. I should be able to delegate a good chunk of the methods to >>>> TimeHelpers.jt*, so there shouldn't be any *redundant* code. Is that a >>>> reasonable compromise? >>>> >>> >>> Yes, as long as import Helpers._ is not incompatible with importing >>> whatever trait you come up with. >>> >>> >>>> >>>> Derek >>>> >>>> >>>> On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker < >>>> dchenbec...@gmail.com> wrote: >>>> >>>>> I agree that the goal isn't to remove java.util.Date. For trivial time >>>>> handling it works just fine. What I'm trying to achieve here is a way to >>>>> make Joda Time be the default impl while leaving the user a choice. By >>>>> using >>>>> separate traits instead of different names on the same trait, we achieve a >>>>> few things: >>>>> >>>>> 1. A consistent API for both java.util and Joda Time in terms of >>>>> method names. As Naftoli pointed out, people expect naming of functions >>>>> consistent with what they do and having two different "now"s on the >>>>> same >>>>> trait is going to look a little strange to people, I think. >>>>> 2. A clean *optional* usage of Joda Time. If we put code that >>>>> utilizes Joda Time directly into TimeHelpers then it's not an optional >>>>> dependency. Making a separate trait means that if someone doesn't use >>>>> the >>>>> Joda Time trait then they don't need to have the Joda Time jar in their >>>>> classpath and they never know that it's not there. >>>>> 3. A relatively simple code change path to move from java.util to >>>>> Joda Time by simply changing imports. >>>>> >>>>> Your assertion that Date is a simple wrapper for a Long timestamp is >>>>> pretty accurate, but really Joda Time's DateTime is a superset of >>>>> *Calendar*, not Date. Just look at what we had to do with >>>>> CalendarExtension >>>>> to get some simple date manipulation functions, where those same methods >>>>> are >>>>> already defined on DateTime. The vast majority of Joda Time's classes are >>>>> immutable, and the mutators return new instances instead of modifying the >>>>> current instance. TimeSpan's current handling of duration addition doesn't >>>>> cope with DST, which I'm sure will show up as a bug in someone's code if >>>>> it >>>>> hasn't already. Having done a fair amount of java.util.Date handling and >>>>> then moving to Joda Time, I find it hard to call the difference between >>>>> the >>>>> two APIs "marginal". In any case, I still feel that my proposal makes Joda >>>>> Time available in a nicer way while leaving existing code completely >>>>> untouched (by introducing a JodaHelpers trait that mirrors Helpers). >>>>> >>>>> Derek >>>>> >>>>> >>>>> On Tue, Oct 20, 2009 at 9:25 PM, David Pollak < >>>>> feeder.of.the.be...@gmail.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim < >>>>>> naftoli...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> I agree with this. >>>>>>> My understanding is that the goal is that Lift should use Joda for >>>>>>> its time functions rather than java.util. >>>>>> >>>>>> >>>>>> This is not the goal. The goal is to make JodeTime available. There >>>>>> is no reason to remove support for java.util.Date. None. >>>>>> >>>>>> JodaTime offers some advantages, but there's no reason, none, nada, to >>>>>> *remove* support for java.util.Date. >>>>>> >>>>>> I'm cool with different names (not jtNow, but choose something else). >>>>>> >>>>>> But I view removal of support for java.util.Date as gratuitous. Sure, >>>>>> if we were to make the clean-slate decision today, I'd opt for primary >>>>>> support of JodaTime and secondary support for java.util.Date. But we're >>>>>> making a decision based on legacy. We're not going to cut off >>>>>> java.util.Date just because something marginally better (and I'm not >>>>>> being facetious here... at the bottom, these are just wrappers for >>>>>> number of >>>>>> milliseconds since Jan 1, 1970). >>>>>> >>>>>> >>>>>>> If the Joda methods have different and longer names, then it's >>>>>>> existing side by side with the java.util implementation, not replacing >>>>>>> it. >>>>>>> To many people, it is important that methods etc. should be named >>>>>>> properly and aesthetically. It's not pleasant to use names like "jtNow" >>>>>>> in >>>>>>> your code when that is the method that gets used normally. Sure, if >>>>>>> 'now' >>>>>>> was the usual method and a 'jtNow' method was called in special >>>>>>> circumstances, it's an understandable name. But names that are used in >>>>>>> ordinary circumstances should have straightforward names. >>>>>>> (Names should be concise expressions of what they represent. This >>>>>>> aids in memorization and code readability.) >>>>>>> Also, it will be impossible to deprecate the java.util implementation >>>>>>> and have a clean API instead. If we use separate traits with the same >>>>>>> method >>>>>>> names, then we will be able to. >>>>>>> >>>>>>> >>>>>>> ------------------------------------- >>>>>>> Derek Chen-Becker<dchenbec...@gmail.com> wrote: >>>>>>> >>>>>>> On Tue, Oct 20, 2009 at 4:59 PM, David Pollak < >>>>>>> feeder.of.the.be...@gmail.com >>>>>>> > wrote: >>>>>>> >>>>>>> > What I checked in allows you to use JodaTime just as easily (well >>>>>>> with 2 >>>>>>> > extra characters in a few method names) as java.util.Date. How is >>>>>>> anything >>>>>>> > more "default" than that? >>>>>>> > >>>>>>> >>>>>>> My primary concern with this approach is that it makes changing >>>>>>> between the >>>>>>> two implementations something that requires a global search and >>>>>>> replace on >>>>>>> one or more method names, whereas having two different implementation >>>>>>> traits >>>>>>> means that generally I should be able to just change the import and >>>>>>> the code >>>>>>> will work. A secondary (minor) concern is that having method names >>>>>>> reflect >>>>>>> the underlying implementation details goes against my aesthetics. >>>>>>> >>>>>>> >>>>>>> > It's an interesting difference between an OO vs. non-OO. In the >>>>>>> > implementation I created, there choice of one or the other is made >>>>>>> based on >>>>>>> > singleton methods invoked. This allows mixing both in the same >>>>>>> code simply >>>>>>> > by invoking now or jtNow. >>>>>>> > >>>>>>> >>>>>>> I would argue that it's not a common case where you would want to use >>>>>>> both >>>>>>> libraries, particularly when Joda's DateTime has an explicit toDate >>>>>>> on it >>>>>>> that returns a java.util.Date. There are similar methods to return >>>>>>> Calendar >>>>>>> and TimeZone instances as needed. These are simple methods to use >>>>>>> directly, >>>>>>> or it's easy to create a view that handles this automatically. >>>>>>> >>>>>>> I'm unclear why this is not possible. We can add a DSL for >>>>>>> manipulating >>>>>>> > JodaTime without breaking anything we have. The TimeSpan class >>>>>>> simply gets >>>>>>> > enhanced to deal with additional stuff and maybe uses JodaTime >>>>>>> under the >>>>>>> > covers. >>>>>>> > >>>>>>> >>>>>>> The underpinning of the current DSL is the TimeSpan class. Joda Time >>>>>>> already >>>>>>> has a time interval class corresponding to TimeSpan called Duration, >>>>>>> but the >>>>>>> more proper class to use is actually Period. Period is premised not >>>>>>> on ms >>>>>>> duration but rather on field deltas, which allows it to properly >>>>>>> handle DST. >>>>>>> Modifying the current DSL to work for Duration and Period via >>>>>>> TimeSpan is >>>>>>> just going to end up with a lot of redundant code, when a Joda-only >>>>>>> DSL >>>>>>> would be cleaner and more in line with how you would want to use Joda >>>>>>> Time. >>>>>>> >>>>>>> >>>>>>> > They have that now with the implementation I did on your branch. >>>>>>> > >>>>>>> >>>>>>> Like I said before, I have a strong preference for the OO approach >>>>>>> and being >>>>>>> able to change impls by changing the import rather than having to >>>>>>> change >>>>>>> methods all over the place. If you really feel strongly that we can't >>>>>>> have a >>>>>>> separate trait in Lift, I can just create a different artifact in my >>>>>>> own >>>>>>> repo that tracks Lift and create the JodaHelpers, JodaTimeFormats and >>>>>>> JodaTimeHelpers traits there. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Derek >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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 -~----------~----~----~----~------~----~------~--~---
