groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Laforge <glafo...@gmail.com>
Subject Re: Java 8 Date/Time API Extension Methods
Date Tue, 27 Jun 2017 14:31:28 GMT
Sure, when you're ready / happy, feel free to start a thread on the dev
list.

On Tue, Jun 27, 2017 at 4:48 AM, Joe Wolf <joewolf@gmail.com> wrote:

> I'm all on board for integrating into Groovy, and I'm letting that drive
> design decisions as I finish up the changes. I appreciate the feedback on
> the API--I will definitely take it all under consideration. Perhaps we
> should move integration-related discussions over to the dev mailing list.
>
> -Joe
>
> On Mon, Jun 26, 2017 at 7:51 AM, Guillaume Laforge <glaforge@gmail.com>
> wrote:
>
>> I also think it's sane to keep the Java 8 ordering in this case.
>>
>> Even if we can use ranges, keeping upto / downto in addition would be
>> kind to people used to using them.
>>
>> Anyhow, very nice work!
>> I still believe we need to integrate it to Groovy core :-)
>>
>> Guillaume
>>
>> On Mon, Jun 26, 2017 at 8:10 AM, Ahm Avoby <aliencheckout@gmail.com>
>> wrote:
>>
>>> 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>
>>>>>
>>>>
>>>>
>>
>>
>> --
>> 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>
>>
>
>


-- 
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