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