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