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
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
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
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
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
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
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
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
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)
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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]
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
47 matches
Mail list logo
