[Lift] Re: Are we willing to make a breaking change for Joda Time?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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 -~--~~~~--~~--~--~---
