I'll make these changes and work on improving the internal implementation of TimeSpan and TimeHelpers to work better within the existing method signatures, but I want to be clear that I'm extremely unhappy that I can't be accommodated otherwise.
Thanks, Derek On Fri, Oct 23, 2009 at 5:05 PM, David Pollak <[email protected] > wrote: > > > On Fri, Oct 23, 2009 at 3:53 PM, Derek Chen-Becker > <[email protected]>wrote: > >> 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. > > > now, today and epoch are not part of TimeSpan. > > Update TimeSpan to *internally* use Periods. Don't break the interface to > TimeSpan. If you add methods to TimeSpan, that's fine. > > Please add additional methods to TimeHelpers that support returning the > JodaTime equivalents of what now, today, and epoch return. > > >> 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 < >> [email protected]> wrote: >> >>> >>> >>> On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker < >>> [email protected]> 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 < >>>> [email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker < >>>>> [email protected]> 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 < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker < >>>>>>> [email protected]> 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 < >>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim < >>>>>>>>>> [email protected]> 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<[email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>> On Tue, Oct 20, 2009 at 4:59 PM, David Pollak < >>>>>>>>>>> [email protected] >>>>>>>>>>> > 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 >>> >>> >>> >> >> >> > > > -- > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
