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