I could do that, but I would still have an ambiguous definition of "now",
"today", "epoch", etc if I want to use Joda Time and the requirement is that
an import Helpers._ cannot conflict. The whole reason that I want to write a
separate trait is that Lift currently has some nice convenience methods and
a DSL in TimeHelpers, but they all return java.util.{Calendar,Date}. I'm
just trying to mirror the API usage, except have everything return Joda Time
classes instead. That way, I can upgrade all of my current Lift apps to use
Joda Time simply by changing the import. It's entirely subjective, but I
just strongly dislike the idea of using method names like jtNow, etc.
Anthony brings up a good point about Joda Time in large part becoming the
new Java Date/Time API, but we can always deal with that when it comes
along.Derek On Fri, Oct 23, 2009 at 4:00 PM, David Pollak <feeder.of.the.be...@gmail.com > wrote: > > > On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker > <dchenbec...@gmail.com>wrote: > >> 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. >> > > So, why not make TimeSpan use Period, but preserve the interface so you can > build one with millis and get it to spit out millis or Period as the case > may be? > > >> >> 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 >>> >>> >>> >> >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
