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 <glafo...@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 <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 <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>
>
