groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ahm Avoby <aliencheck...@gmail.com>
Subject Re: Java 8 Date/Time API Extension Methods
Date Mon, 26 Jun 2017 06:10:50 GMT
Hi Jim,

@static parse(): I am with you on keeping the Java 8 API ordering, but I
would not jettison the upto and downto methods, as to not confuse people
switching from Java 8 to Groovy.

Cheers,
Ahm


Joe Wolf <joewolf@gmail.com> schrieb am So., 25. Juni 2017, 23:32:

> 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