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 -~----------~----~----~----~------~----~------~--~---
