On Mon, Oct 19, 2009 at 10:53 AM, Derek Chen-Becker <dchenbec...@gmail.com>wrote:
> That's pretty much my take. The whole Java Calendar/Date/Timezone impl is > poorly designed, hence Joda Time. > > Now I've run into another wall, this time with the TimeSpanBuilder. I > can't mask the implicits from long/int to TimeSpanBuilder, so I can't define > the same DSL for things like "3 seconds", etc. I tried to provide an > implicit conversion from TimeSpan to JodaSpan but that won't cover all of > the cases and this is feeling increasingly ugly as I add more and more > layers and implicit defs to work around the old API. > > At this point, the only way that this may work is if I create and entirely > new JodaHelpers object that extends all of the Helpers traits, replacing > TimeHelpers with my new JodaTimeHelpers trait. This may be the path of least > pain, but it means two cycles of deprecation: one to deprecate the current > TimeHelpers in favor of JodaTimeHelpers, and the second to deprecate > JodaTimeHelpers back to a refactored/reworked TimeHelpers. Does this sound > like a reasonable approach, or is this getting too crazy? > > The other option I thought of is to make a new branch just for this and > just track master with the branch. The big downside is that this doubles the > release work to have a Joda Lift and non-Joda Lift. > > Thoughts? > I'm always on the side of less work, and less clutter. What about keeping the old stuff deprecated (and unmaintained) till 1.5 or 2.0, and encouraging the use of the JodaTimeHelpers in the mean time. That gives existing code time to be transitioned to the new stuff...... > Derek > > > On Mon, Oct 19, 2009 at 11:17 AM, rstradling <ryanstradl...@gmail.com>wrote: > >> >> Take my input or vote of confidence with a grain of salt... >> I had to use java.util.Calendar recently and noticed some of the >> issues with it that you mention. For my case, I created a light >> wrapper for my use of java.util.Calendar that redefined the relevant >> statics (Monday, Tuesday, etc) as Scala "enumerations" and then >> provided some implicit conversions to go from DayOfWeek.Monday to >> java.util.Calendar.Monday. My hope is that client code never knows >> that they are using java.util.Calendar and that they will also get >> some level of type-safety by using my wrapper. >> >> >> In summary, I do not like the design of java.util.Calendar because of >> its inconsistencies and think that creating a more consistent way of >> doing things is a "good thing." >> >> >> >> >> >> On Oct 18, 10:58 am, Derek Chen-Becker <dchenbec...@gmail.com> wrote: >> > OK, I've run into an issue that makes me really uncomfortable. >> > java.util.Calender is generally 1-based for fields, except for month of >> > year, which is zero-based. This inconsistency has bled through to the >> > TimeHelpers API. I can't just change this, because that would break a >> lot of >> > code, possibly at runtime. What I would like to do is make a >> corresponding >> > set of field accessor methods (day, month, year) in the JodaTimeHelpers >> > trait that behave just like TimeHelpers, and then I'm building an >> "extender" >> > class that will wrap a DateTime to provide functionality very similar to >> > what Scala Time does (it's mostly pretty simple). The other >> inconsistency in >> > the API is that some fields are UTC relative (day, month, year), but >> others >> > aren't (currentYear). To address this, I would like to make all of my >> > extender class methods use the local timezone, and provide a utc method >> that >> > will return an extender relative to UTC. That way you could do things >> like: >> > >> > now.days // day of month relative to local timezone >> > now.utc.days // day of month relative to UTC >> > >> > Thoughts? >> > >> > Derek >> > >> > On Thu, Oct 15, 2009 at 5:18 PM, David Pollak < >> feeder.of.the.be...@gmail.com >> > >> > > wrote: >> > > I'd prefer not the break the apis without deprecating them first >> > >> > > On Thu, Oct 15, 2009 at 4:09 PM, Derek Chen-Becker < >> dchenbec...@gmail.com>wrote: >> > >> > >> Just asking, since I'm looking at bolting a lot of java.util.Date >> methods >> > >> onto the innards of TimeHelpers so that the specs pass. >> > >> > >> Derek >> > >> > > -- >> > > Lift, the simply functional web frameworkhttp://liftweb.net >> > > Beginning Scalahttp://www.apress.com/book/view/1430219890 >> > > Follow me:http://twitter.com/dpp >> > > Surf the harmonics >> >> > > > > -- James A Barrows --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
