groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Wolf <joew...@gmail.com>
Subject Re: Java 8 Date/Time API Extension Methods
Date Sun, 25 Jun 2017 21:31:45 GMT
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 <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Mime
View raw message