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.com>wrote:
>
>> 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 "now"s 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-Becker<dchenbec...@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>
>>>
>>>
>>
>>
>>
>
>
> --
> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to