groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jim northrop <james.b.north...@googlemail.com>
Subject Re: Java 8 Date/Time API Extension Methods
Date Mon, 26 Jun 2017 05:42:23 GMT
Lovely piece of work Joe! 👏 Bet you needed a few aspirins to complete this baby. Can we
do date arithmetic like 'new Date()+7 days'. or similar? Or maybe thats not part of your code?

Sent from my iPad

> On 25 Jun 2017, at 23:31, Joe Wolf <joewolf@gmail.com> wrote:
> 
> Goodtimes 1.1 is out with new extension methods on the zone-based types, effectively
covering the entire java.time.* package (except for Clock, which I haven't found need to extend).
I'd say I'm about 98% content with the API.
> 
> I'm mulling the addition of static parse() methods akin to the Groovy JDK's Date.parse(String
format, String input) method, but am wrestling with argument ordering. Date.parse accepts
the format as the first argument; the new java.time API parse methods accept the date/time
string first. Although I've aimed to be consistent with the Groovy JDK thus far, I'm leaning
towards following the Java 8 API ordering in this case.
> 
> On the other side of the coin, I am contemplating jettisoning the upto and downto methods.
Since the java.time types are Comparable and goodtimes adds next() and previous() methods,
the range operator can be used to replicate their function
> 
> earlier.upto(later) {} --> (earlier..later).each {}
> later.downto(earlier) {} --> (later..earlier).each {}
> 
> I'm also questioning the existence of the getAt(int calendarField) methods. On the downside,
it's munging the older java.util API with the new; on the upside, I don't have to explicitly
import java.time.temporal.ChronoField. java.util.Calendar comes for free.
> 
> -Joe
> 
>> On Fri, Jun 9, 2017 at 8:51 AM, Guillaume Laforge <glaforge@gmail.com> wrote:
>> Keep us updated on the new extensions, and once you're happy with what you have come
up with, I believe it'd really be awesome to have it integrated.
>> 
>> Guillaume
>> 
>> 
>>> On Fri, Jun 9, 2017 at 5:07 AM, Joe Wolf <joewolf@gmail.com> wrote:
>>> +1 for me. I think it's a good idea.
>>> 
>>> Not everything in the current API may be worthwhile to have as part of Groovy
proper, though. For example, the bridging methods from the java.time classes back to Date
and Calendar could be unnecessarily promoting the latter's usage.
>>> 
>>> By the way, I'm currently working to add extension methods to the java.time types
involving ZoneId and ZoneOffset. I hope to have that completed in a couple of weeks or so.
>>> 
>>> -Joe
>>> 
>>>> On Thu, Jun 8, 2017 at 7:52 PM, Mario Garcia <mario.ggar@gmail.com>
wrote:
>>>> +1 
>>>> 
>>>> I think Many Groovy applications could benefit from having this in Groovy.
>>>> 
>>>> 2017-06-09 1:02 GMT+02:00 Paul King <paulk@asert.com.au>:
>>>>> +1 from me, but I'd be keen to hear Joe's thoughts?
>>>>> 
>>>>> Cheers, Paul.
>>>>> 
>>>>> 
>>>>>> On Thu, Jun 8, 2017 at 10:37 PM, Dinko Srkoč <dinko.srkoc@gmail.com>
wrote:
>>>>>> On 8 June 2017 at 13:34, Russel Winder <russel@winder.org.uk>
wrote:
>>>>>> > On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote:
>>>>>> >> On 8 June 2017 at 13:09, Russel Winder <russel@winder.org.uk>
wrote:
>>>>>> >> > On Wed, 2017-06-07 at 14:38 +0000, Søren Berg Glasius
wrote:
>>>>>> >> > > I think it makes perfect sense that you can do
the same
>>>>>> >> > > calculations
>>>>>> >> > > with
>>>>>> >> > > java.time.* as you can with java.util.Date
>>>>>> >> > >
>>>>>> >> >
>>>>>> >> > Shouldn't it be fair to assume that all new code eschews
>>>>>> >> > java.util.Date
>>>>>> >> > and all the Calendar stuff, and uses java.time for
everything time
>>>>>> >> > and
>>>>>> >> > date related?
>>>>>> >>
>>>>>> >> I think this falls into a category of "hope" or "wish",
rather than
>>>>>> >> "assumption" :-)
>>>>>> >
>>>>>> > True, but I was hoping that unlike a large percentage of Java
>>>>>> > developers who are hugely reluctant to learn anything new they
do not
>>>>>> > already know (*), Groovy developers were very much into using
the best
>>>>>> > new idiomatic ways of doing things (well except for stuff that
is just
>>>>>> > fashionably trendy for a few days) and keeping their codebases
up to
>>>>>> > date with up-to-date Groovy.
>>>>>> >
>>>>>> > Please do not shatter my illusions.
>>>>>> 
>>>>>> haha!
>>>>>> 
>>>>>> Okay, I could convince myself that it is indeed so with Groovy developers.
:-)
>>>>>> 
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > (*) And are thus part of the legacy problem.
>>>>>> >
>>>>>> > --
>>>>>> > Russel.
>>>>>> > =============================================================================
>>>>>> > Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net
>>>>>> > 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk
>>>>>> > London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>> 
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge / Google+
> 

Mime
View raw message