groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jim northrop <james.b.north...@googlemail.com>
Subject Re: Java 8 Date/Time API Extension Methods
Date Mon, 26 Jun 2017 06:48:51 GMT
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 <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 / Google+
>> 

Mime
View raw message