Right Ahm,
Good point. Backward compatibility helps not only us old-time groovy ppl but
also the new generation of converts to Groovy 👍✅
Sent from my iPad
> On 26 Jun 2017, at 08:10, Ahm Avoby <aliencheck...@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 <joew...@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 <glafo...@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 <joew...@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.g...@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 <pa...@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.sr...@gmail.com>
>>>>>>> wrote:
>>>>>>> On 8 June 2017 at 13:34, Russel Winder <rus...@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 <rus...@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.win...@ekiga.net
>>>>>>> > 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@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+
>>
