[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-25 Thread David Pollak
I made my decision. It's not open for any more debate (that's what happens when there's a BDFL around... he can make a final decision). I listened to your position as you have articulated it in this thread. I seriously and deeply considered your position and those of others. But I made a

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-24 Thread Jeppe Nejsum Madsen
Derek Chen-Becker dchenbec...@gmail.com writes: [...] It's entirely subjective, but I just strongly dislike the idea of using method names like jtNow, etc. I couldn't agree morecode just doesn't read nice anymore. /Jeppe --~--~-~--~~~---~--~~ You

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-24 Thread David Pollak
On Sat, Oct 24, 2009 at 3:05 AM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote: Derek Chen-Becker dchenbec...@gmail.com writes: [...] It's entirely subjective, but I just strongly dislike the idea of using method names like jtNow, etc. I couldn't agree morecode just doesn't read nice

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-24 Thread Naftoli Gugenheim
Well if users would, for at least one release, explicitly say which time library they want to use, this kind of bug would not occur. It's not 'jt' per se; rather, as Derek said, it's having names that indicate the implementation detail rather than simply what it does. It makes code less

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread David Pollak
On Wed, Oct 21, 2009 at 7:20 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: 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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread Derek Chen-Becker
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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: 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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread Derek Chen-Becker
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. On Fri, Oct

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: 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)

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread aw
That's pretty much my take. The whole Java Calendar/Date/Timezone impl is poorly designed, hence Joda Time. I like Joda Time too, and used to be apprehensive about integrating it as a dependency into my projects -- at least for simple things that I could probably do with Date/Calendar, just

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread Derek Chen-Becker
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. The whole reason that I want to write a separate trait is that Lift currently has some nice convenience methods and

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread David Pollak
On Fri, Oct 23, 2009 at 3:53 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: 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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-23 Thread Derek Chen-Becker
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,

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-21 Thread Derek Chen-Becker
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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-20 Thread Derek Chen-Becker
Here is my argument for breaking it out: I think that we're in agreement that the *default* impl for Lift should eventually be Joda Time, after some period of deprecation on the old stuff. I also agree with your earlier comment that it should be something that the developer can choose. I'm sure

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-20 Thread Derek Chen-Becker
s/version 1.2-final/some future version/ On Tue, Oct 20, 2009 at 8:01 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: Here is my argument for breaking it out: I think that we're in agreement that the *default* impl for Lift should eventually be Joda Time, after some period of deprecation

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-20 Thread David Pollak
On Tue, Oct 20, 2009 at 7:01 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: Here is my argument for breaking it out: I think that we're in agreement that the *default* impl for Lift should eventually be Joda Time, after some period of deprecation on the old stuff. What I checked in

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-20 Thread Derek Chen-Becker
Or, if you're OK with it, I could just make a lift-joda module that has the traits. That would also keep the Joda Time dependency out of the main lift modules. On Tue, Oct 20, 2009 at 5:48 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: On Tue, Oct 20, 2009 at 4:59 PM, David Pollak

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-20 Thread Naftoli Gugenheim
I agree with this. My understanding is that the goal is that Lift should use Joda for its time functions rather than java.util. 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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-20 Thread David Pollak
On Tue, Oct 20, 2009 at 6:56 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: 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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread rstradling
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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Jim Barrows
I've been thinking a lot about the issue of backwards compatibility, and the trade off with good architecture. I've come to the conclusion that the only real answer is that you have to take each instance on a case by case basis and ask yourself this question: Do you want to write a thunking layer

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Jim Barrows
On Mon, Oct 19, 2009 at 10:53 AM, Derek Chen-Becker dchenbec...@gmail.comwrote: 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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Jeppe Nejsum Madsen
Derek Chen-Becker dchenbec...@gmail.com writes: 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

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
I've just looked at the code. There's nothing that's going to be incompatible moving to JodaTime. Sure, the month method will have a different result if you pass it a JodaTime instance than in you pass it a Date instance. If this is documented, then it's not a problem. Existing methods don't

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
The major issue is the time DSL. Everything else works fine by masking the definitions with a later import, e.g. import Helpers._ import JodaTimeHelpers._ The problem is that implicit defs (views) don't mask, so I can't override or mask it so that 3 seconds returns a Joda Time Duration, which is

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
I spoke too soon. If I try to do masking imports, I get errors about ambiguous defs: [WARNING] /home/software/liftweb/lift-util/src/test/scala/net/liftweb/util/JodaTimeHelpersSpec.scala:71: error: reference to now is ambiguous; [WARNING] it is imported twice in the same scope by [WARNING] import

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
What branch is the code on? On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: I spoke too soon. If I try to do masking imports, I get errors about ambiguous defs: [WARNING]

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
wip-dcb-issue-89-jodatime. I just checked in everything I have, which means that branch currently doesn't compile. Maybe I'm overthinking it, but TimeHelpers does define some nice convenience methods and my goal is to replicate and extend that with Joda Time. Derek On Mon, Oct 19, 2009 at 3:13

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
Please take a look at http://github.com/dpp/liftweb/commit/8b5ad6d7fac428886a74356150b332443e4443e7 I think I've got JodaTime and the existing code playing nicely together. On Mon, Oct 19, 2009 at 2:23 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: wip-dcb-issue-89-jodatime. I just checked

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
Well, yes. I actually had similar code working, but what I was trying to avoid is a situation where someone has code like: import Helpers._ .. val someTime = now + ( 3 minutes) and then to use this code with JodaTime they need to change it to val someTime = jtNow + (3 minutes) and then when

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
We'll deprecate the Date/Calendar stuff. I'm not sure we're going to remove it any time soon (in the next year +). Personally, I don't see a compelling reason to remove it from the code base (there may be people who would prefer not to use JodaTime). So, we might need better names than jtNow,

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
What I was thinking earlier is that we can simply make a JodaHelpers object that mixes in JodaTimeHelpers instead of TimeHelpers. That way, code changes to move to Joda Time would mostly just be an import change instead of having to alter every instance of now ⇒ jtNow. Derek On Mon, Oct 19, 2009

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
Along those same lines, maybe there should be a common trait that doesn't define an impl, and then have separate Joda and java.util impl traits that don't mix directly into Helpers. On Mon, Oct 19, 2009 at 6:57 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: What I was thinking earlier is

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Naftoli Gugenheim
Since there are anyway minor breaking changes in 1.1, maybe it's worth it to take TimeHelpers out of Helpers. This way, it will simply require an extra import, of either TimeHelpers or JodaHelpers, which can be chosen by the individual developer. Whenever someone is ready to migrate, they will

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
That was pretty much what I was trying to communicate with my last email, just not very effectively. Derek On Mon, Oct 19, 2009 at 7:14 PM, Naftoli Gugenheim naftoli...@gmail.comwrote: Since there are anyway minor breaking changes in 1.1, maybe it's worth it to take TimeHelpers out of

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread Derek Chen-Becker
Oh, that was a sidetrack. I was thinking that it could help enforce the common contract, but return types are different for the same method names so that really wouldn't work. I really just want to try and separate them out, or provide a different Helpers that provides JodaTime stuff under the

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-19 Thread David Pollak
I have a strong preference not to break the TimeHelpers out of Helpers. I'm not seeing the problem with additional methods on TimeHelpers that do the JodaTime thing. Can you guys help me understand your point of view. On Mon, Oct 19, 2009 at 8:16 PM, Derek Chen-Becker

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-16 Thread Charles F. Munat
You have looked at Scala Time, right? I think some of this may already be implemented there, and it would probably be better to extend that rather than reinvent it. But maybe I'm thinking about something else? http://github.com/jorgeortiz85/scala-time Chas. Derek Chen-Becker wrote: Oh, I

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-16 Thread Timothy Perrett
I thought we had this discussion in some other thread and because scala-time wasn't 1.0 there was a general reluctancy to use it? We could cherry pick some of the code however; im sure Jorge wouldn't mind :-) Cheers, Tim On 16 Oct 2009, at 11:30, Charles F. Munat wrote: You have looked

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-16 Thread David Pollak
On Fri, Oct 16, 2009 at 3:46 AM, Timothy Perrett timo...@getintheloop.euwrote: I thought we had this discussion in some other thread and because scala-time wasn't 1.0 there was a general reluctancy to use it? We could cherry pick some of the code however; im sure Jorge wouldn't mind :-) We

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-16 Thread Naftoli Gugenheim
What's exactly the problem if it's pre 1.0? That it may have bugs? - Derek Chen-Beckerdchenbec...@gmail.com wrote: Right. Fortunately most of the work setting up Joda Time will make switching to Scala Time pretty simple. Derek On Fri, Oct 16, 2009 at 4:46

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-16 Thread Derek Chen-Becker
I haven't even looked at his code yet, so I'll just plug on with straight Joda Time. On Fri, Oct 16, 2009 at 9:01 AM, David Pollak feeder.of.the.be...@gmail.com wrote: On Fri, Oct 16, 2009 at 3:46 AM, Timothy Perrett timo...@getintheloop.euwrote: I thought we had this discussion in some

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-16 Thread David Pollak
On Fri, Oct 16, 2009 at 8:18 AM, Naftoli Gugenheim naftoli...@gmail.comwrote: What's exactly the problem if it's pre 1.0? That it may have bugs? It may have bugs. The APIs may change. Jorge (now that he has a day job) may not continue to maintain it. In general, unless there's a compelling

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-16 Thread Charles F. Munat
I was thinking more that if you're duplicating efforts, why not use those efforts to help Jorge move ScalaTime forward simultaneously? I haven't found any problems with ScalaTime being pre-1.0. It just means that not all Joda functionality is available in ScalaTime, and sometimes you need to

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-15 Thread David Pollak
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.comwrote: 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] Re: Are we willing to make a breaking change for Joda Time?

2009-10-15 Thread Derek Chen-Becker
OK, will do. 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.comwrote: Just asking, since I'm looking at bolting a lot

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-15 Thread Derek Chen-Becker
Well, actually, maybe I'll just make a JodaHelpers with the applicable methods on it and we can just deprecate the entire TimeHelpers object. If anyone else has a better idea I'm all ears. Derek On Thu, Oct 15, 2009 at 5:22 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: OK, will do. On

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-15 Thread David Pollak
I personally like the DSLs that TimeHelpers provides. I'd hate to see it deprecated or go away without the ability to write 30 seconds later using some other DSL. On Thu, Oct 15, 2009 at 5:22 PM, Derek Chen-Becker dchenbec...@gmail.comwrote: Well, actually, maybe I'll just make a JodaHelpers

[Lift] Re: Are we willing to make a breaking change for Joda Time?

2009-10-15 Thread Derek Chen-Becker
Oh, I plan on incorporating the DSL. My thought was that JodaHelpers would define most of the same methods as TimeHelpers, just operating on DateTime instead of Date and Calendar. Then you could do import ...Helpers._ import ...JodaHelpers._ and the latter import would mask the TimeHelpers