[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 decision
and the discussion is over.

On Sat, Oct 24, 2009 at 8:29 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:


 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 readable.
 We required everyone to update their imports for Box and actors. I think
 your argument is that requiring such changes should only be done when there
 is a big enough gain. So the disagreement seems to be whether allowing
 people to use JodaTime code that's as readable as java.util time is
 important enough. Or whether names like 'jtNow' are less readable.
 Another point. If JDK 7 time is not 100% compatible with JodaTime, if we
 take TimeHelpers out of Helpers, having all 3 play together nicely is
 straightforward. On the other hand, if we try to squeeze in new names, we
 will have to add even more of them.
 And say some company wants to add their own time API.


 -
 David Pollakfeeder.of.the.be...@gmail.com wrote:

 On Sat, Oct 24, 2009 at 3:05 AM, Jeppe Nejsum Madsen je...@ingolfs.dk
 wrote:

 
  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.
 

 I'm cool with other names, but, and this is a huge *BUT*...

 having two methods that have different return signatures is a huge source
 of
 bugs.  We saw this when we changed some of the S methods to return
 Box[String] rather than String.  There were hundreds of subtle errors.

 I'm happy to deprecate now and have goodNow (returns JodaTime) and evilNow
 (returns java.util.Date), but I am 100% against changing a return
 signature.

 I am sorry that my position is making folks unhappy, especially Derek who
 works hard and does a great job.

 Thanks,

 David


 
  /Jeppe
 
  
 


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



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



[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 anymore.


I'm cool with other names, but, and this is a huge *BUT*...

having two methods that have different return signatures is a huge source of
bugs.  We saw this when we changed some of the S methods to return
Box[String] rather than String.  There were hundreds of subtle errors.

I'm happy to deprecate now and have goodNow (returns JodaTime) and evilNow
(returns java.util.Date), but I am 100% against changing a return signature.

I am sorry that my position is making folks unhappy, especially Derek who
works hard and does a great job.

Thanks,

David



 /Jeppe

 



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



[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 
readable.
We required everyone to update their imports for Box and actors. I think your 
argument is that requiring such changes should only be done when there is a big 
enough gain. So the disagreement seems to be whether allowing people to use 
JodaTime code that's as readable as java.util time is important enough. Or 
whether names like 'jtNow' are less readable.
Another point. If JDK 7 time is not 100% compatible with JodaTime, if we take 
TimeHelpers out of Helpers, having all 3 play together nicely is 
straightforward. On the other hand, if we try to squeeze in new names, we will 
have to add even more of them.
And say some company wants to add their own time API.


-
David Pollakfeeder.of.the.be...@gmail.com wrote:

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 anymore.


I'm cool with other names, but, and this is a huge *BUT*...

having two methods that have different return signatures is a huge source of
bugs.  We saw this when we changed some of the S methods to return
Box[String] rather than String.  There were hundreds of subtle errors.

I'm happy to deprecate now and have goodNow (returns JodaTime) and evilNow
(returns java.util.Date), but I am 100% against changing a return signature.

I am sorry that my position is making folks unhappy, especially Derek who
works hard and does a great job.

Thanks,

David



 /Jeppe

 



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



[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
 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 nows 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-Beckerdchenbec...@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 

[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 with TimeHelpers already in scope there would be ambiguous
implicit conversions from Long/Int to TimeSpan or Period. Supposedly, 2.8
will have some support for masking or overriding implicits, but I don't want
to rely on that in the short term. If a JodaHelpers trait that would replace
a Helpers import isn't OK then I can just do this in my own repo.

Thanks,

Derek

On Fri, Oct 23, 2009 at 2:52 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



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

[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
 like to have the time DSL be based on Periods instead of millisecond
 durations, and with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


What is the advantage of using Period internally instead of milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding implicits,
 but I don't want to rely on that in the short term. If a JodaHelpers trait
 that would replace a Helpers import isn't OK then I can just do this in my
 own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



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

[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 23, 2009 at 3:37 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 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
 like to have the time DSL be based on Periods instead of millisecond
 durations, and with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



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

[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)
 if needed, so it's a superset of the current functionality of TimeSpan.


So, why not make TimeSpan use Period, but preserve the interface so you can
build one with millis and get it to spit out millis or Period as the case
may be?



 On Fri, Oct 23, 2009 at 3:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 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 with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



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

[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 more hassle...  But I am
less apprehensive now that I know that Stephen Colebourne from Joda-
Time is developing JSR-310 (https://jsr-310.dev.java.net/) -- a new
Date and Time API for Java 7.  If you look at the API, the new
javax.time is basically stealing (I mean integrating) all of the best
parts of Joda-Time.

Now, I am happily using org.joda.time.LocalDate because I know that
eventually, I will just need to change my imports to upgrade to
javax.time.calendar.LocalDate.


I haven't had a close look at Scala-Time, but I am not sure if I
understand the value when using straight Joda Time with Scala was so
painless.  But I am sure there is room to leverage Scala features for
things like implicit conversions.

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



[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
a DSL in TimeHelpers, but they all return java.util.{Calendar,Date}. I'm
just trying to mirror the API usage, except have everything return Joda Time
classes instead. That way, I can upgrade all of my current Lift apps to use
Joda Time simply by changing the import. It's entirely subjective, but I
just strongly dislike the idea of using method names like jtNow, etc.
Anthony brings up a good point about Joda Time in large part becoming the
new Java Date/Time API, but we can always deal with that when it comes
along.

Derek

On Fri, Oct 23, 2009 at 4:00 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 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)
 if needed, so it's a superset of the current functionality of TimeSpan.


 So, why not make TimeSpan use Period, but preserve the interface so you can
 build one with millis and get it to spit out millis or Period as the case
 may be?



 On Fri, Oct 23, 2009 at 3:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



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

[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 part of TimeSpan.

Update TimeSpan to *internally* use Periods.  Don't break the interface to
TimeSpan.  If you add methods to TimeSpan, that's fine.

Please add additional methods to TimeHelpers that support returning the
JodaTime equivalents of what now, today, and epoch return.


 The whole reason that I want to write a separate trait is that Lift
 currently has some nice convenience methods and a DSL in TimeHelpers, but
 they all return java.util.{Calendar,Date}. I'm just trying to mirror the API
 usage, except have everything return Joda Time classes instead. That way, I
 can upgrade all of my current Lift apps to use Joda Time simply by changing
 the import. It's entirely subjective, but I just strongly dislike the idea
 of using method names like jtNow, etc. Anthony brings up a good point about
 Joda Time in large part becoming the new Java Date/Time API, but we can
 always deal with that when it comes along.

 Derek


 On Fri, Oct 23, 2009 at 4:00 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 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.


 So, why not make TimeSpan use Period, but preserve the interface so you
 can build one with millis and get it to spit out millis or Period as the
 case may be?



 On Fri, Oct 23, 2009 at 3:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of
 milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



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

[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, David Pollak feeder.of.the.be...@gmail.com
 wrote:



 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 part of TimeSpan.

 Update TimeSpan to *internally* use Periods.  Don't break the interface to
 TimeSpan.  If you add methods to TimeSpan, that's fine.

 Please add additional methods to TimeHelpers that support returning the
 JodaTime equivalents of what now, today, and epoch return.


 The whole reason that I want to write a separate trait is that Lift
 currently has some nice convenience methods and a DSL in TimeHelpers, but
 they all return java.util.{Calendar,Date}. I'm just trying to mirror the API
 usage, except have everything return Joda Time classes instead. That way, I
 can upgrade all of my current Lift apps to use Joda Time simply by changing
 the import. It's entirely subjective, but I just strongly dislike the idea
 of using method names like jtNow, etc. Anthony brings up a good point about
 Joda Time in large part becoming the new Java Date/Time API, but we can
 always deal with that when it comes along.

 Derek


 On Fri, Oct 23, 2009 at 4:00 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:55 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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.


 So, why not make TimeSpan use Period, but preserve the interface so you
 can build one with millis and get it to spit out millis or Period as the
 case may be?



 On Fri, Oct 23, 2009 at 3:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



 On Fri, Oct 23, 2009 at 2:35 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 with TimeHelpers already in scope there would be ambiguous
 implicit conversions from Long/Int to TimeSpan or Period.


 What is the advantage of using Period internally instead of
 milliseconds?


 Supposedly, 2.8 will have some support for masking or overriding
 implicits, but I don't want to rely on that in the short term. If a
 JodaHelpers trait that would replace a Helpers import isn't OK then I can
 just do this in my own repo.

 Thanks,

 Derek


 On Fri, Oct 23, 2009 at 2:52 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:



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

[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 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?

Derek

On Tue, Oct 20, 2009 at 11:35 PM, Derek Chen-Becker
dchenbec...@gmail.comwrote:

 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 nows 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.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 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-Beckerdchenbec...@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 

[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 there will be cases where people want to use
java.util instead of Joda Time because of preference or constraint (say, no
external jars). The problem is that import Helpers._ is a very common
import, and by having TimeHelpers be part of Helpers it makes it very
difficult to do a clean separation of impls. My main example is the time
manipulation DSL. We can't mask the implicit defs that are already part of
TimeHelpers, so it's very difficult (maybe impossible) to define a Joda Time
based DSL (which would properly handle things like daylight savings time,
etc). By removing TimeHelpers from Helpers, it means that the user can have
absolute control over which time handling impl they're using without having
to give up all of the nice things in Helpers. It would be a breaking change
to code, but it would be pretty minor, since the fix is just to add an
import to the code that breaks. Here is my proposal for how we change
things:


   - *version 1.1-final*:


   1. Rename the current TimeHelpers trait to JavaTimeHelpers and add a new
  TimeHelpers trait that extends JavaTimeHelpers, providing an alias. This
  means no breaking code in this release.
  2. Create a new JodaTimeHelpers that mirrors the non-deprecated
  functionality of JavaTimeHelpers (there were already some
deprecated methods
  on TimeHelpers that could go away).
  3. We can also copy back some of the new methods on JodaTimeHelpers
  and refactor them for java.util (I'm thinking epoch and some other minor
  ones).
  4. Add a JavaTimeFormatting and JodaTimeFormatting trait (currently
  TimeRules in my code) that allows for custom formats and format
functions of
  dates and times. The reason I want to split out the impls here, just like
  Java/JodaTimeHelpers, is so that Joda can be an optional dependency for
  people who can't use it.


   - *version 1.2-final*:


   1. Remove the TimeHelpers trait and remove TimeHelpers from Helpers. At
   this point, people would have to explicitly choose JavaTimeHelpers or
   JodaTimeHelpers in their import statement to determine which impl they're
   using.

The main thing is that having TimeHelpers tied to Helpers makes it very
difficult to give the user a choice of impls, something that I feel strongly
goes against how Lift does things otherwise.

Derek

On Mon, Oct 19, 2009 at 10:36 PM, David Pollak 
feeder.of.the.be...@gmail.com wrote:

 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 
 dchenbec...@gmail.comwrote:

 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 same
 method names. My goal is really to minimize code changes, so one or two
 imports instead of a lot of find/replace (as simple as that may be) would be
 preferable in my book.

 Derek


 On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim 
 naftoli...@gmail.comwrote:


 What would be the purpose of having a common trait though?

 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 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.com
 wrote:

 
  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 be able to do so on a
  file-by-file (or import-scope-by-import-scope) basis.
  Eventually JodaHelpers could be included in Helpers.
 
 
  -
  Derek Chen-Beckerdchenbec...@gmail.com wrote:
 
  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.com
  wrote:
 
   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

[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 on the old stuff.
 I also agree with your earlier comment that it should be something that the
 developer can choose. I'm sure there will be cases where people want to use
 java.util instead of Joda Time because of preference or constraint (say, no
 external jars). The problem is that import Helpers._ is a very common
 import, and by having TimeHelpers be part of Helpers it makes it very
 difficult to do a clean separation of impls. My main example is the time
 manipulation DSL. We can't mask the implicit defs that are already part of
 TimeHelpers, so it's very difficult (maybe impossible) to define a Joda Time
 based DSL (which would properly handle things like daylight savings time,
 etc). By removing TimeHelpers from Helpers, it means that the user can have
 absolute control over which time handling impl they're using without having
 to give up all of the nice things in Helpers. It would be a breaking change
 to code, but it would be pretty minor, since the fix is just to add an
 import to the code that breaks. Here is my proposal for how we change
 things:


- *version 1.1-final*:


1. Rename the current TimeHelpers trait to JavaTimeHelpers and add a
   new TimeHelpers trait that extends JavaTimeHelpers, providing an alias. 
 This
   means no breaking code in this release.
   2. Create a new JodaTimeHelpers that mirrors the non-deprecated
   functionality of JavaTimeHelpers (there were already some deprecated 
 methods
   on TimeHelpers that could go away).
   3. We can also copy back some of the new methods on JodaTimeHelpers
   and refactor them for java.util (I'm thinking epoch and some other minor
   ones).
   4. Add a JavaTimeFormatting and JodaTimeFormatting trait (currently
   TimeRules in my code) that allows for custom formats and format 
 functions of
   dates and times. The reason I want to split out the impls here, just 
 like
   Java/JodaTimeHelpers, is so that Joda can be an optional dependency for
   people who can't use it.


- *version 1.2-final*:


1. Remove the TimeHelpers trait and remove TimeHelpers from Helpers. At
this point, people would have to explicitly choose JavaTimeHelpers or
JodaTimeHelpers in their import statement to determine which impl they're
using.

 The main thing is that having TimeHelpers tied to Helpers makes it very
 difficult to give the user a choice of impls, something that I feel strongly
 goes against how Lift does things otherwise.

 Derek


 On Mon, Oct 19, 2009 at 10:36 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 dchenbec...@gmail.com
  wrote:

 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 same
 method names. My goal is really to minimize code changes, so one or two
 imports instead of a lot of find/replace (as simple as that may be) would be
 preferable in my book.

 Derek


 On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim naftoli...@gmail.com
  wrote:


 What would be the purpose of having a common trait though?

 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 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 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 be able to do so on a
  file-by-file (or import-scope-by-import-scope) basis.
  Eventually JodaHelpers could be included in Helpers.
 
 
  -
  Derek Chen-Beckerdchenbec...@gmail.com wrote:
 
  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.com
  wrote:
 
   What I was thinking earlier is that we can simply 

[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 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?


 I also agree with your earlier comment that it should be something that the
 developer can choose. I'm sure there will be cases where people want to use
 java.util instead of Joda Time because of preference or constraint (say, no
 external jars). The problem is that import Helpers._ is a very common
 import, and by having TimeHelpers be part of Helpers it makes it very
 difficult to do a clean separation of impls.


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.


 My main example is the time manipulation DSL. We can't mask the implicit
 defs that are already part of TimeHelpers, so it's very difficult (maybe
 impossible) to define a Joda Time based DSL (which would properly handle
 things like daylight savings time, etc).


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.


 By removing TimeHelpers from Helpers, it means that the user can have
 absolute control over which time handling impl they're using without having
 to give up all of the nice things in Helpers.


They have that now with the implementation I did on your branch.




 It would be a breaking change to code, but it would be pretty minor, since
 the fix is just to add an import to the code that breaks. Here is my
 proposal for how we change things:


- *version 1.1-final*:


1. Rename the current TimeHelpers trait to JavaTimeHelpers and add a
   new TimeHelpers trait that extends JavaTimeHelpers, providing an alias. 
 This
   means no breaking code in this release.
   2. Create a new JodaTimeHelpers that mirrors the non-deprecated
   functionality of JavaTimeHelpers (there were already some deprecated 
 methods
   on TimeHelpers that could go away).
   3. We can also copy back some of the new methods on JodaTimeHelpers
   and refactor them for java.util (I'm thinking epoch and some other minor
   ones).
   4. Add a JavaTimeFormatting and JodaTimeFormatting trait (currently
   TimeRules in my code) that allows for custom formats and format 
 functions of
   dates and times. The reason I want to split out the impls here, just 
 like
   Java/JodaTimeHelpers, is so that Joda can be an optional dependency for
   people who can't use it.


- *version 1.2-final*:


1. Remove the TimeHelpers trait and remove TimeHelpers from Helpers. At
this point, people would have to explicitly choose JavaTimeHelpers or
JodaTimeHelpers in their import statement to determine which impl they're
using.

 The main thing is that having TimeHelpers tied to Helpers makes it very
 difficult to give the user a choice of impls, something that I feel strongly
 goes against how Lift does things otherwise.

 Derek


 On Mon, Oct 19, 2009 at 10:36 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 dchenbec...@gmail.com
  wrote:

 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 same
 method names. My goal is really to minimize code changes, so one or two
 imports instead of a lot of find/replace (as simple as that may be) would be
 preferable in my book.

 Derek


 On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim naftoli...@gmail.com
  wrote:


 What would be the purpose of having a common trait though?

 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 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 Helpers. This way, it will simply require
 an
  extra import, of either 

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


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



[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 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-Beckerdchenbec...@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



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



[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 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-Beckerdchenbec...@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 

[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 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.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, the simply functional web frameworkhttp://liftweb.net
  Beginning Scalahttp://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
-~--~~~~--~~--~--~---



[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 between the better architecture and
worse architecture for the next 20 years, and what is that going to cost the
sanity of everyone who comes after?
I think in this case, given the mind numbingly idiotic date and calendar
handling in java, I would answer Dear God, I'd rather dive into a pool
filled with double edged razor blades then ever have to deal java.util.Date
or Calendar again.
I say this because Date and Calendar have been broken since 1.0.1, when I
started working with Java.  Sun/Oracle obviously has no intention of giving
us anything better, so it's up to us to do it.  Doing it now, while the
existing code base of lift is small, is much better then doing it on down
the line.  Ideally I'd like to see this abomination fixed at the Scala
level, rather then the Lift level, but I'll take my sanity savers where I
can.

On Mon, Oct 19, 2009 at 10:17 AM, rstradling ryanstradl...@gmail.comwrote:


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



[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 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.comwrote:


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



[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 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.

I haven't looked very closely at the current code, so don't really know
what the issues are. but this won't stop me from commenting. I'm
really looking forward to get rid of Calendar and friends

 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?

Depending on the cycle-length, this doesn't sound too bad. But if it is
1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
has numerous breaking changes so if a cycle is just a milestone release
then I think it's fine.

  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.

Doesn't sound like a viable approach. We'll be carrying this baggage
forever (unless this was only a temp solution?)

/Jeppe


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



[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 get changed.  For methods that return a Date or
Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
returns a JodaTime instance.

Existing methods that take a Date or Calendar, there'll be parallel methods
that take a JodaTime instance.

Where does this seem unworkable?



On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:


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

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  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?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   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.

 Doesn't sound like a viable approach. We'll be carrying this baggage
 forever (unless this was only a temp solution?)

 /Jeppe


 



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



[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 a cleaner
way of representing time durations in milliseconds. In order to get a better
discussion going, I'll go ahead and comment out my refactored DSL and put up
the code that does work this afternoon and we can discuss it from there.

Derek

On Mon, Oct 19, 2009 at 1:37 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 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 get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel methods
 that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen je...@ingolfs.dkwrote:


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

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  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?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   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.

 Doesn't sound like a viable approach. We'll be carrying this baggage
 forever (unless this was only a temp solution?)

 /Jeppe






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



[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 _root_.net.liftweb.util.JodaTimeHelpers._
[WARNING] and import _root_.net.liftweb.util.TimeHelpers._
[WARNING]   3.seconds.later.millis must beCloseTo((now +
3.seconds).millis, 100L)

Since TimeHelpers is automatically part of Helpers, and import Helpers._
is a pretty common import, it's going to require some other mechanism to get
the proper import into scope. Any solution which results in now returning
a java.util.Date essentially defeats the purpose of moving to Joda Time,
since you can just do

  /** transforms a java.util.Date to a org.joda.time.DateTime */
  implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

  /** transforms an org.joda.time.DateTime to a java.util.Date */
  implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

in your code and get most of it for free. What I'm trying to achieve here is
a refactoring of Lift's time formatting and processing API that lends itself
to clean usage of JodaTime.

Derek

On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 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 a
 cleaner way of representing time durations in milliseconds. In order to get
 a better discussion going, I'll go ahead and comment out my refactored DSL
 and put up the code that does work this afternoon and we can discuss it from
 there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dkwrote:


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

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  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?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   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.

 Doesn't sound like a viable approach. We'll be carrying this baggage
 forever (unless this was only a temp solution?)

 /Jeppe






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

[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]
 /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 _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import Helpers._
 is a pretty common import, it's going to require some other mechanism to get
 the proper import into scope. Any solution which results in now returning
 a java.util.Date essentially defeats the purpose of moving to Joda Time,
 since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve here
 is a refactoring of Lift's time formatting and processing API that lends
 itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 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 a
 cleaner way of representing time durations in milliseconds. In order to get
 a better discussion going, I'll go ahead and comment out my refactored DSL
 and put up the code that does work this afternoon and we can discuss it from
 there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dkwrote:


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

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  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?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   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.

 Doesn't sound like a viable approach. We'll be carrying this baggage
 forever (unless this was only a temp solution?)

 /Jeppe






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

[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 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 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]
 /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 _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import Helpers._
 is a pretty common import, it's going to require some other mechanism to get
 the proper import into scope. Any solution which results in now returning
 a java.util.Date essentially defeats the purpose of moving to Joda Time,
 since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve here
 is a refactoring of Lift's time formatting and processing API that lends
 itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 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 a
 cleaner way of representing time durations in milliseconds. In order to get
 a better discussion going, I'll go ahead and comment out my refactored DSL
 and put up the code that does work this afternoon and we can discuss it from
 there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen je...@ingolfs.dk
  wrote:


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

 I haven't looked very closely at the current code, so don't really know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  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?

 Depending on the cycle-length, this doesn't sound too bad. But if it is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1
 already
 has numerous breaking changes so if a cycle is just a milestone release
 then I think it's fine.

   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.

 Doesn't sound like a viable approach. We'll be 

[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 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 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 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 _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which results in
 now returning a java.util.Date essentially defeats the purpose of moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve here
 is a refactoring of Lift's time formatting and processing API that lends
 itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 a cleaner way of representing time durations in milliseconds. In order 
 to
 get a better discussion going, I'll go ahead and comment out my refactored
 DSL and put up the code that does work this afternoon and we can discuss it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dk wrote:


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

 I haven't looked very closely at the current code, so don't really
 know
 what the issues are. but this won't stop me from commenting. I'm
 really looking forward to get rid of Calendar and friends

  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?

 Depending on the cycle-length, this doesn't sound too bad. But if it
 is
 1.3 before we get pure JodaTime, this sounds excessive. Lift 1.1
 already
 has numerous breaking changes so if a cycle is just a milestone
 release
 then I think it's 

[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 we remove the current java.util impl they would have to switch
back to the original code. Also, because of all of these issues I haven't
fully worked out things like JodaSpanBuilder, which should really be using
JodaTime's Periods instead of Durations since those take into account things
like daylight savings time and leap years (none of the current code does
that right now, java.util or JodaTime). If this is the best compromise we
can come up with I'll just make a new branch to finish working on the
JodaTime side of things.

Thanks,

Derek

On Mon, Oct 19, 2009 at 4:57 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 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 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 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which results 
 in
 now returning a java.util.Date essentially defeats the purpose of moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 a cleaner way of representing time durations in milliseconds. In order 
 to
 get a better discussion going, I'll go ahead and comment out my refactored
 DSL and put up the code that does work this afternoon and we can discuss 
 it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 get changed.  For methods that return a Date or
 Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dk wrote:


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

 I haven't looked very 

[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, etc., but
I'm not expecting to make now return a DateTime.

On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker dchenbec...@gmail.comwrote:

 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 remove the current java.util impl they would have to
 switch back to the original code. Also, because of all of these issues I
 haven't fully worked out things like JodaSpanBuilder, which should really be
 using JodaTime's Periods instead of Durations since those take into account
 things like daylight savings time and leap years (none of the current code
 does that right now, java.util or JodaTime). If this is the best compromise
 we can come up with I'll just make a new branch to finish working on the
 JodaTime side of things.

 Thanks,

 Derek


 On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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.com
  wrote:

 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 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which results 
 in
 now returning a java.util.Date essentially defeats the purpose of moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 a cleaner way of representing time durations in milliseconds. In 
 order to
 get a better discussion going, I'll go ahead and comment out my 
 refactored
 DSL and put up the code that does work this afternoon and we can discuss 
 it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 get changed.  For methods that return a Date
 or Calendar, there'll be a parallel method (e.g., jNow or somesuch) that
 returns a JodaTime instance.

 Existing methods that take a Date or Calendar, there'll be parallel
 methods that take a JodaTime instance.

 Where does this seem unworkable?




 On Mon, Oct 19, 2009 at 12:26 PM, Jeppe Nejsum Madsen 
 je...@ingolfs.dk wrote:


 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.



[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 at 6:12 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 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, etc., but I'm not expecting to make now return a DateTime.


 On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker 
 dchenbec...@gmail.comwrote:

 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 remove the current java.util impl they would have to
 switch back to the original code. Also, because of all of these issues I
 haven't fully worked out things like JodaSpanBuilder, which should really be
 using JodaTime's Periods instead of Durations since those take into account
 things like daylight savings time and leap years (none of the current code
 does that right now, java.util or JodaTime). If this is the best compromise
 we can come up with I'll just make a new branch to finish working on the
 JodaTime side of things.

 Thanks,

 Derek


 On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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.com wrote:

 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 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which 
 results in
 now returning a java.util.Date essentially defeats the purpose of 
 moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 a cleaner way of representing time durations in milliseconds. In 
 order to
 get a better discussion going, I'll go ahead and comment out my 
 refactored
 DSL and put up the code that does work this afternoon and we can 
 discuss it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 get changed.  For methods that return a Date
 or Calendar, there'll be a parallel method (e.g., jNow or somesuch) 
 that
 returns a JodaTime instance.

 Existing methods 

[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 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 at 6:12 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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, etc., but I'm not expecting to make now return a DateTime.


 On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 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 remove the current java.util impl they would have to
 switch back to the original code. Also, because of all of these issues I
 haven't fully worked out things like JodaSpanBuilder, which should really be
 using JodaTime's Periods instead of Durations since those take into account
 things like daylight savings time and leap years (none of the current code
 does that right now, java.util or JodaTime). If this is the best compromise
 we can come up with I'll just make a new branch to finish working on the
 JodaTime side of things.

 Thanks,

 Derek


 On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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.com wrote:

 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 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which 
 results in
 now returning a java.util.Date essentially defeats the purpose of 
 moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new
 DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 a cleaner way of representing time durations in milliseconds. In 
 order to
 get a better discussion going, I'll go ahead and comment out my 
 refactored
 DSL and put up the code that does work this afternoon and we can 
 discuss it
 from there.

 Derek


 On Mon, Oct 19, 2009 at 1:37 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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 

[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 be able to do so on a 
file-by-file (or import-scope-by-import-scope) basis.
Eventually JodaHelpers could be included in Helpers.


-
Derek Chen-Beckerdchenbec...@gmail.com wrote:

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 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 at 6:12 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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, etc., but I'm not expecting to make now return a DateTime.


 On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker dchenbec...@gmail.com
  wrote:

 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 remove the current java.util impl they would have to
 switch back to the original code. Also, because of all of these issues I
 haven't fully worked out things like JodaSpanBuilder, which should really be
 using JodaTime's Periods instead of Durations since those take into account
 things like daylight savings time and leap years (none of the current code
 does that right now, java.util or JodaTime). If this is the best compromise
 we can come up with I'll just make a new branch to finish working on the
 JodaTime side of things.

 Thanks,

 Derek


 On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 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.com wrote:

 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 PM, David Pollak 
 feeder.of.the.be...@gmail.com wrote:

 What branch is the code on?


 On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 _root_.net.liftweb.util.JodaTimeHelpers._
 [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
 [WARNING]   3.seconds.later.millis must beCloseTo((now +
 3.seconds).millis, 100L)

 Since TimeHelpers is automatically part of Helpers, and import
 Helpers._ is a pretty common import, it's going to require some other
 mechanism to get the proper import into scope. Any solution which 
 results in
 now returning a java.util.Date essentially defeats the purpose of 
 moving
 to Joda Time, since you can just do

   /** transforms a java.util.Date to a org.joda.time.DateTime */
   implicit def dateToDateTime(in : Date) : DateTime = new
 DateTime(in)

   /** transforms an org.joda.time.DateTime to a java.util.Date */
   implicit def dateTimeToDate(in : DateTime) : Date = in.toDate

 in your code and get most of it for free. What I'm trying to achieve
 here is a refactoring of Lift's time formatting and processing API that
 lends itself to clean usage of JodaTime.

 Derek


 On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
 dchenbec...@gmail.com wrote:

 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 a cleaner way of 

[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 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 be able to do so on a
 file-by-file (or import-scope-by-import-scope) basis.
 Eventually JodaHelpers could be included in Helpers.


 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 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.com
 wrote:

  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 at 6:12 PM, David Pollak 
  feeder.of.the.be...@gmail.com wrote:
 
  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, etc., but I'm not expecting to make now return a DateTime.
 
 
  On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker 
 dchenbec...@gmail.com
   wrote:
 
  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 remove the current java.util impl they would have to
  switch back to the original code. Also, because of all of these issues
 I
  haven't fully worked out things like JodaSpanBuilder, which should
 really be
  using JodaTime's Periods instead of Durations since those take into
 account
  things like daylight savings time and leap years (none of the current
 code
  does that right now, java.util or JodaTime). If this is the best
 compromise
  we can come up with I'll just make a new branch to finish working on
 the
  JodaTime side of things.
 
  Thanks,
 
  Derek
 
 
  On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
  feeder.of.the.be...@gmail.com wrote:
 
  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.com wrote:
 
  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 PM, David Pollak 
  feeder.of.the.be...@gmail.com wrote:
 
  What branch is the code on?
 
 
  On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
  dchenbec...@gmail.com wrote:
 
  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 _root_.net.liftweb.util.JodaTimeHelpers._
  [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
  [WARNING]   3.seconds.later.millis must beCloseTo((now +
  3.seconds).millis, 100L)
 
  Since TimeHelpers is automatically part of Helpers, and import
  Helpers._ is a pretty common import, it's going to require some
 other
  mechanism to get the proper import into scope. Any solution which
 results in
  now returning a java.util.Date essentially defeats the purpose of
 moving
  to Joda Time, since you can just do
 
/** transforms a java.util.Date to a org.joda.time.DateTime */
implicit def dateToDateTime(in : Date) : DateTime = new
  DateTime(in)
 
/** transforms an org.joda.time.DateTime to a java.util.Date */
implicit def dateTimeToDate(in : DateTime) : Date = in.toDate
 
  in your code and get most of it for free. What I'm trying to
 achieve
  here is a refactoring of Lift's time formatting and processing API
 that
  lends itself to clean usage of JodaTime.
 
  Derek
 
 
  On Mon, Oct 19, 2009 at 2:01 PM, Derek Chen-Becker 
  dchenbec...@gmail.com wrote:
 
  The 

[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 same
method names. My goal is really to minimize code changes, so one or two
imports instead of a lot of find/replace (as simple as that may be) would be
preferable in my book.

Derek

On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim naftoli...@gmail.comwrote:


 What would be the purpose of having a common trait though?

 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 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.com
 wrote:

 
  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 be able to do so on a
  file-by-file (or import-scope-by-import-scope) basis.
  Eventually JodaHelpers could be included in Helpers.
 
 
  -
  Derek Chen-Beckerdchenbec...@gmail.com wrote:
 
  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.com
  wrote:
 
   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 at 6:12 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   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, etc., but I'm not expecting to make now return a DateTime.
  
  
   On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker 
  dchenbec...@gmail.com
wrote:
  
   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 remove the current java.util impl they would have to
   switch back to the original code. Also, because of all of these
 issues
  I
   haven't fully worked out things like JodaSpanBuilder, which should
  really be
   using JodaTime's Periods instead of Durations since those take into
  account
   things like daylight savings time and leap years (none of the current
  code
   does that right now, java.util or JodaTime). If this is the best
  compromise
   we can come up with I'll just make a new branch to finish working on
  the
   JodaTime side of things.
  
   Thanks,
  
   Derek
  
  
   On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   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.com wrote:
  
   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 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   What branch is the code on?
  
  
   On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   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 _root_.net.liftweb.util.JodaTimeHelpers._
   [WARNING] and import _root_.net.liftweb.util.TimeHelpers._
   [WARNING]   3.seconds.later.millis must beCloseTo((now +
   3.seconds).millis, 100L)
  
   Since TimeHelpers is automatically part of Helpers, and 

[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 dchenbec...@gmail.comwrote:

 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 same
 method names. My goal is really to minimize code changes, so one or two
 imports instead of a lot of find/replace (as simple as that may be) would be
 preferable in my book.

 Derek


 On Mon, Oct 19, 2009 at 8:53 PM, Naftoli Gugenheim 
 naftoli...@gmail.comwrote:


 What would be the purpose of having a common trait though?

 -
 Derek Chen-Beckerdchenbec...@gmail.com wrote:

 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.com
 wrote:

 
  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 be able to do so on a
  file-by-file (or import-scope-by-import-scope) basis.
  Eventually JodaHelpers could be included in Helpers.
 
 
  -
  Derek Chen-Beckerdchenbec...@gmail.com wrote:
 
  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.com
  wrote:
 
   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 at 6:12 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   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, etc., but I'm not expecting to make now return a DateTime.
  
  
   On Mon, Oct 19, 2009 at 5:03 PM, Derek Chen-Becker 
  dchenbec...@gmail.com
wrote:
  
   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 remove the current java.util impl they would have
 to
   switch back to the original code. Also, because of all of these
 issues
  I
   haven't fully worked out things like JodaSpanBuilder, which should
  really be
   using JodaTime's Periods instead of Durations since those take into
  account
   things like daylight savings time and leap years (none of the
 current
  code
   does that right now, java.util or JodaTime). If this is the best
  compromise
   we can come up with I'll just make a new branch to finish working on
  the
   JodaTime side of things.
  
   Thanks,
  
   Derek
  
  
   On Mon, Oct 19, 2009 at 4:57 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   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.com wrote:
  
   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 PM, David Pollak 
   feeder.of.the.be...@gmail.com wrote:
  
   What branch is the code on?
  
  
   On Mon, Oct 19, 2009 at 1:25 PM, Derek Chen-Becker 
   dchenbec...@gmail.com wrote:
  
   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] 

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

2009-10-18 Thread Derek Chen-Becker
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.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, 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
-~--~~~~--~~--~--~---



[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 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 methods. Or you could 
 just import JodaHelpers by itself. Actually, Joda Time has some very 
 nice facilities for doing intervals that would simplify the DSLs a lot 
 and possibly make it richer.
 
 Derek
 
 On Thu, Oct 15, 2009 at 7:19 PM, David Pollak 
 feeder.of.the.be...@gmail.com mailto:feeder.of.the.be...@gmail.com 
 wrote:
 
 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.com mailto:dchenbec...@gmail.com wrote:
 
 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.com mailto:dchenbec...@gmail.com wrote:
 
 OK, will do.
 
 
 On Thu, Oct 15, 2009 at 5:18 PM, David Pollak
 feeder.of.the.be...@gmail.com
 mailto: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 mailto: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 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
-~--~~~~--~~--~--~---



[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 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 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 methods. Or you  
 could
 just import JodaHelpers by itself. Actually, Joda Time has some very
 nice facilities for doing intervals that would simplify the DSLs a  
 lot
 and possibly make it richer.

 Derek

 On Thu, Oct 15, 2009 at 7:19 PM, David Pollak
 feeder.of.the.be...@gmail.com  
 mailto:feeder.of.the.be...@gmail.com
 wrote:

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.com mailto:dchenbec...@gmail.com wrote:

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.com mailto:dchenbec...@gmail.com wrote:

OK, will do.


On Thu, Oct 15, 2009 at 5:18 PM, David Pollak
feeder.of.the.be...@gmail.com
mailto: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 mailto: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 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
-~--~~~~--~~--~--~---



[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 can't grab source code from other projects.  The only code that goes into
the Lift repository is code written by committers explicitly for Lift.  That
way the code provenance is clear and the IP is clean.



 Cheers, Tim

 On 16 Oct 2009, at 11:30, Charles F. Munat wrote:

 
  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 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 methods. Or you
  could
  just import JodaHelpers by itself. Actually, Joda Time has some very
  nice facilities for doing intervals that would simplify the DSLs a
  lot
  and possibly make it richer.
 
  Derek
 
  On Thu, Oct 15, 2009 at 7:19 PM, David Pollak
  feeder.of.the.be...@gmail.com
  mailto:feeder.of.the.be...@gmail.com
  wrote:
 
 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.com mailto:dchenbec...@gmail.com wrote:
 
 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.com mailto:dchenbec...@gmail.com wrote:
 
 OK, will do.
 
 
 On Thu, Oct 15, 2009 at 5:18 PM, David Pollak
 feeder.of.the.be...@gmail.com
 mailto: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 mailto: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 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
 
 
 
 
 
 
  
 


 



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



[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 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 :-)

 Cheers, Tim

 On 16 Oct 2009, at 11:30, Charles F. Munat wrote:

 
  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 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 methods. Or you
  could
  just import JodaHelpers by itself. Actually, Joda Time has some very
  nice facilities for doing intervals that would simplify the DSLs a
  lot
  and possibly make it richer.
 
  Derek
 
  On Thu, Oct 15, 2009 at 7:19 PM, David Pollak
  feeder.of.the.be...@gmail.com
  mailto:feeder.of.the.be...@gmail.com
  wrote:
 
 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.com mailto:dchenbec...@gmail.com wrote:
 
 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.com mailto:dchenbec...@gmail.com wrote:
 
 OK, will do.
 
 
 On Thu, Oct 15, 2009 at 5:18 PM, David Pollak
 feeder.of.the.be...@gmail.com
 mailto: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 mailto: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 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
-~--~~~~--~~--~--~---



[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 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 can't grab source code from other projects.  The only code that goes
 into the Lift repository is code written by committers explicitly for Lift.
  That way the code provenance is clear and the IP is clean.



 Cheers, Tim

 On 16 Oct 2009, at 11:30, Charles F. Munat wrote:

 
  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 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 methods. Or you
  could
  just import JodaHelpers by itself. Actually, Joda Time has some very
  nice facilities for doing intervals that would simplify the DSLs a
  lot
  and possibly make it richer.
 
  Derek
 
  On Thu, Oct 15, 2009 at 7:19 PM, David Pollak
  feeder.of.the.be...@gmail.com
  mailto:feeder.of.the.be...@gmail.com
  wrote:
 
 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.com mailto:dchenbec...@gmail.com wrote:
 
 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.com mailto:dchenbec...@gmail.com wrote:
 
 OK, will do.
 
 
 On Thu, Oct 15, 2009 at 5:18 PM, David Pollak
 feeder.of.the.be...@gmail.com
 mailto: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 mailto: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 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
 
 
 
 
 
 
  
 






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



[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 reason, we're not going to put =
1.0 Lift on  1.0 packages.



 -
 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 AM, Timothy Perrett timo...@getintheloop.eu
 wrote:

 
  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 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 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 methods. Or you
   could
   just import JodaHelpers by itself. Actually, Joda Time has some very
   nice facilities for doing intervals that would simplify the DSLs a
   lot
   and possibly make it richer.
  
   Derek
  
   On Thu, Oct 15, 2009 at 7:19 PM, David Pollak
   feeder.of.the.be...@gmail.com
   mailto:feeder.of.the.be...@gmail.com
   wrote:
  
  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.com mailto:dchenbec...@gmail.com wrote:
  
  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.com mailto:dchenbec...@gmail.com wrote:
  
  OK, will do.
  
  
  On Thu, Oct 15, 2009 at 5:18 PM, David Pollak
  feeder.of.the.be...@gmail.com
  mailto: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 mailto: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 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
  
  
  
  
  
  
   
  
 
 
  
 



 



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



[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 use JodaTime directly. It's not like it crashes. Jorge has 
done a superb job.

I am using ScalaTime with Lift on production sites. (And persisting it 
in Hibernate as well, using a joda-hibernate library that isn't quite 
1.0 either, IIRC.)

Food for thought, anyway.

Chas.

Timothy Perrett wrote:
 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 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 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 methods. Or you  
 could
 just import JodaHelpers by itself. Actually, Joda Time has some very
 nice facilities for doing intervals that would simplify the DSLs a  
 lot
 and possibly make it richer.

 Derek

 On Thu, Oct 15, 2009 at 7:19 PM, David Pollak
 feeder.of.the.be...@gmail.com  
 mailto:feeder.of.the.be...@gmail.com
 wrote:

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.com mailto:dchenbec...@gmail.com wrote:

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.com mailto:dchenbec...@gmail.com wrote:

OK, will do.


On Thu, Oct 15, 2009 at 5:18 PM, David Pollak
feeder.of.the.be...@gmail.com
mailto: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 mailto: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 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
-~--~~~~--~~--~--~---



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



[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 of java.util.Date methods
 onto the innards of TimeHelpers so that the specs pass.

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



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



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



[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 methods. Or you could just
import JodaHelpers by itself. Actually, Joda Time has some very nice
facilities for doing intervals that would simplify the DSLs a lot and
possibly make it richer.

Derek

On Thu, Oct 15, 2009 at 7:19 PM, David Pollak feeder.of.the.be...@gmail.com
 wrote:

 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 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.com
  wrote:

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