Groovy 4 planning

classic Classic list List threaded Threaded
11 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Groovy 4 planning

paulk_asert

Hi everyone,

I plan to do a beta-2 of 3.0.0 in a few weeks and then hopefully we'll start the ramp down to final with one or more RCs. When we get to the RCs stage, I'll make a 3_0_X branch. At this stage I don't foresee a 3.1 version but we can certainly do one if desired/needed. So, I'll make master Groovy 4 at that point.

What do people think about changing our maven coordinates with Groovy 4 from org.codehaus.groovy to org.apache.groovy?

Also, if you have anything you'd particularly like to see in Groovy 4, please discuss. I'll have a slide on potential things in Groovy 4 in my gr8conf talk next week. I'd like to include as many sensible ideas as possible to make use of the opportunity to garner feedback on what our users are looking for.

Some of the things currently on my list:
* improved module support (including split package final steps)
* further invoke dynamic improvements (including deferred merge to indy only)
* stream-based replacements for XmlSlurper et al
* groovydoc rework (assuming we manage to finish porting the current groovydoc to 3)
* improved built-in type checking extensions (@NonNull et al)

Let me know what is on your lists of things you'd like to see.

Cheers, Paul.

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 4 planning

Roman Shaposhnik-2
On Thu, May 23, 2019 at 5:28 PM Paul King <[hidden email]> wrote:
>
>
> Hi everyone,
>
> I plan to do a beta-2 of 3.0.0 in a few weeks and then hopefully we'll start the ramp down to final with one or more RCs. When we get to the RCs stage, I'll make a 3_0_X branch. At this stage I don't foresee a 3.1 version but we can certainly do one if desired/needed. So, I'll make master Groovy 4 at that point.
>
> What do people think about changing our maven coordinates with Groovy 4 from org.codehaus.groovy to org.apache.groovy?

Huge +1 to that!

> Also, if you have anything you'd particularly like to see in Groovy 4, please discuss. I'll have a slide on potential things in Groovy 4 in my gr8conf talk next week. I'd like to include as many sensible ideas as possible to make use of the opportunity to garner feedback on what our users are looking for.
>
> Some of the things currently on my list:
> * improved module support (including split package final steps)
> * further invoke dynamic improvements (including deferred merge to indy only)
> * stream-based replacements for XmlSlurper et al

that'd be great to have.

> * groovydoc rework (assuming we manage to finish porting the current groovydoc to 3)
> * improved built-in type checking extensions (@NonNull et al)
>
> Let me know what is on your lists of things you'd like to see.

Thanks,
Roman.
Reply | Threaded
Open this post in threaded view
|

Re: Groovy 4 planning

Simon Sadedin
In reply to this post by paulk_asert
On Fri, May 24, 2019 at 10:28 AM Paul King <[hidden email]> wrote:
 
Also, if you have anything you'd particularly like to see in Groovy 4, please discuss. I'll have a slide on potential things in Groovy 4 in my gr8conf talk next week. I'd like to include as many sensible ideas as possible to make use of the opportunity to garner feedback on what our users are looking for.

Some of the things currently on my list:
* improved module support (including split package final steps)
* further invoke dynamic improvements (including deferred merge to indy only)
* stream-based replacements for XmlSlurper et al
* groovydoc rework (assuming we manage to finish porting the current groovydoc to 3)
* improved built-in type checking extensions (@NonNull et al)

I am wondering if there would be receptiveness to adding streaming based versions of Groovy's standard collection methods. ie: currently

foo.collect { it * 2 }.grep { it > 10 }.take(3)

fully evaluates the collect, then fully evaluates the grep, finally only to take 3 results. Java streams now solves this as do other languages (python generators, etc), but in Groovy you have to abandon the "groovy" methods and use Java streams (which works somewhat).

I could imagine this could be done just by adding 's' to all the methods:

foo.collects { it * 2 }.greps { it > 10 }.takes(3)

Of course people might find that a bit ugly and there could be different syntaxes or solutions .... but it would be really nice to have this "natively" in Groovy!

Cheers,

Simon




 
Reply | Threaded
Open this post in threaded view
|

Re: Groovy 4 planning

paulk_asert
Yes, I think we'd design things such that we'd have a consistent streaming approach for all things where it made sense, e.g. object collections, XML, SQL, JSON etc. We can debate specific method names down the track.

Cheers, Paul.

On Fri, May 24, 2019 at 2:49 PM Simon Sadedin <[hidden email]> wrote:
On Fri, May 24, 2019 at 10:28 AM Paul King <[hidden email]> wrote:
 
Also, if you have anything you'd particularly like to see in Groovy 4, please discuss. I'll have a slide on potential things in Groovy 4 in my gr8conf talk next week. I'd like to include as many sensible ideas as possible to make use of the opportunity to garner feedback on what our users are looking for.

Some of the things currently on my list:
* improved module support (including split package final steps)
* further invoke dynamic improvements (including deferred merge to indy only)
* stream-based replacements for XmlSlurper et al
* groovydoc rework (assuming we manage to finish porting the current groovydoc to 3)
* improved built-in type checking extensions (@NonNull et al)

I am wondering if there would be receptiveness to adding streaming based versions of Groovy's standard collection methods. ie: currently

foo.collect { it * 2 }.grep { it > 10 }.take(3)

fully evaluates the collect, then fully evaluates the grep, finally only to take 3 results. Java streams now solves this as do other languages (python generators, etc), but in Groovy you have to abandon the "groovy" methods and use Java streams (which works somewhat).

I could imagine this could be done just by adding 's' to all the methods:

foo.collects { it * 2 }.greps { it > 10 }.takes(3)

Of course people might find that a bit ugly and there could be different syntaxes or solutions .... but it would be really nice to have this "natively" in Groovy!

Cheers,

Simon




 
Reply | Threaded
Open this post in threaded view
|

Re: Groovy 4 planning

paulk_asert


On Fri, May 24, 2019 at 3:17 PM Paul King <[hidden email]> wrote:
Yes, I think we'd design things such that we'd have a consistent streaming approach for all things where it made sense, e.g. object collections, XML, SQL, JSON etc. We can debate specific method names down the track.

But keep in mind that the Java libraries have streaming support for object collections baked in - so we should not duplicate unnecessarily but we can improve/finesse as appropriate.
 
Cheers, Paul.

On Fri, May 24, 2019 at 2:49 PM Simon Sadedin <[hidden email]> wrote:
On Fri, May 24, 2019 at 10:28 AM Paul King <[hidden email]> wrote:
 
Also, if you have anything you'd particularly like to see in Groovy 4, please discuss. I'll have a slide on potential things in Groovy 4 in my gr8conf talk next week. I'd like to include as many sensible ideas as possible to make use of the opportunity to garner feedback on what our users are looking for.

Some of the things currently on my list:
* improved module support (including split package final steps)
* further invoke dynamic improvements (including deferred merge to indy only)
* stream-based replacements for XmlSlurper et al
* groovydoc rework (assuming we manage to finish porting the current groovydoc to 3)
* improved built-in type checking extensions (@NonNull et al)

I am wondering if there would be receptiveness to adding streaming based versions of Groovy's standard collection methods. ie: currently

foo.collect { it * 2 }.grep { it > 10 }.take(3)

fully evaluates the collect, then fully evaluates the grep, finally only to take 3 results. Java streams now solves this as do other languages (python generators, etc), but in Groovy you have to abandon the "groovy" methods and use Java streams (which works somewhat).

I could imagine this could be done just by adding 's' to all the methods:

foo.collects { it * 2 }.greps { it > 10 }.takes(3)

Of course people might find that a bit ugly and there could be different syntaxes or solutions .... but it would be really nice to have this "natively" in Groovy!

Cheers,

Simon




 
Reply | Threaded
Open this post in threaded view
|

Re: Groovy 4 planning

Milles, Eric (TR Tech, Content & Ops)
In reply to this post by paulk_asert

My quick list for Groovy 4:


> What do people think about changing our maven coordinates with Groovy 4 from org.codehaus.groovy to org.apache.groovy?


Sounds good in theory.  Would you also repackage all "org.codehaus.*" sources?  Would you publish redirects in maven central so users could still get conflict management for other deps that pull in groovy?

<project

  xmlns="http://maven.apache.org/POM/4.0.0"

  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

                      http://maven.apache.org/xsd/maven-4.0.0.xsd">


  <modelVersion>4.0.0</modelVersion>


  <groupId>org.codehaus.groovy</groupId>

  <artifactId>groovy</artifactId>

  <version>4.0.0</version>


  <distributionManagement>

    <relocation>

      <groupId>org.apache.groovy</groupId>

      <artifactId>groovy</artifactId>

      <version>4.0.0</version>

    </relocation>

  </distributionManagement>

</project>


Eric M.

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 4 planning

Daniel.Sun
Here is my wish list:
* Polish the generics type syntax for closure[1]
* Support generics better in static compilation[2]
* Implement PIC for better performance[3]
* Make groovySh support new features of Groovy3
* Polish bytecode, e.g. eliminate the dead code[4]
* Implement GINQ, i.e. Groovy Integrated Query[5]
* Support incremental compilation
* Implement new MOP
* Improve the gradle build of Apache Groovy(e.g. `compileTestGroovy` always
run even if no test code changes)


Cheers,
Daniel.Sun
[1] https://issues.apache.org/jira/browse/GROOVY-8992
[2] https://issues.apache.org/jira/browse/GROOVY-8409
[3] https://issues.apache.org/jira/browse/GROOVY-8298
[4] https://github.com/jacoco/jacoco/issues/884
[5] https://issues.apache.org/jira/browse/GROOVY-8258




-----
Apache Groovy committer & PMC member
Blog: http://blog.sunlan.me 
Twitter: @daniel_sun

--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Apache Groovy committer & PMC member

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: Groovy 4 planning

Paolo Di Tommaso
In reply to this post by Milles, Eric (TR Tech, Content & Ops)
It sounds a good plan! 

My suggestion is to improve as much as possible the support for native compilation, see for example this thread. There's a lot of excitement in the JVM world at this regard and losing the train can be problematic to keep groovy on the edge. 

Regarding lang enhancements, I would love in Groovy 4 to have raw strings and see solved the problem with the override of equals method for collection objects.


Best,
Paolo

On Fri, May 24, 2019 at 4:27 PM Milles, Eric (TR Tech, Content & Ops) <[hidden email]> wrote:

My quick list for Groovy 4:


> What do people think about changing our maven coordinates with Groovy 4 from org.codehaus.groovy to org.apache.groovy?


Sounds good in theory.  Would you also repackage all "org.codehaus.*" sources?  Would you publish redirects in maven central so users could still get conflict management for other deps that pull in groovy?

<project

  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

                      http://maven.apache.org/xsd/maven-4.0.0.xsd">


  <modelVersion>4.0.0</modelVersion>


  <groupId>org.codehaus.groovy</groupId>

  <artifactId>groovy</artifactId>

  <version>4.0.0</version>


  <distributionManagement>

    <relocation>

      <groupId>org.apache.groovy</groupId>

      <artifactId>groovy</artifactId>

      <version>4.0.0</version>

    </relocation>

  </distributionManagement>

</project>


Eric M.

MG
Reply | Threaded
Open this post in threaded view
|

Re: Groovy 4 planning

MG
In reply to this post by Simon Sadedin
+1 for that, in some cases it is exactly what one needs, and it would be good to have native support for this in Groovy.

Thoughts:
  1. Maybe put the "s" in front as in "scollect" ? This makes it quicker to get the result with Intellisense (type "sco" instead of "collects") and avoids having method names which imply meaning that is not there ("an object 'collects' something (i.e. rocks), instead of "this is the command to collect").
  2. Would it make sense to only have to use the "s"-method for the first call in the call chain, since e.g. "grep" than already sees a stream anyway ?
  3. ...and if yes, would a "streamify" operator be a better option (e.g. foo.>>collect { it * 2 }.grep { it > 10 }.take(3) ) ?
If the idea is to shift things over to using Java 1:1 for streams, then I think we should consider introducing alias methods that follow the Java naming convention for their non-streaming Groovy counterparts (collect/etc) (that might be a good idea any way)...

Cheers,
mg


On 24/05/2019 06:48, Simon Sadedin wrote:
On Fri, May 24, 2019 at 10:28 AM Paul King <[hidden email]> wrote:
 
Also, if you have anything you'd particularly like to see in Groovy 4, please discuss. I'll have a slide on potential things in Groovy 4 in my gr8conf talk next week. I'd like to include as many sensible ideas as possible to make use of the opportunity to garner feedback on what our users are looking for.

Some of the things currently on my list:
* improved module support (including split package final steps)
* further invoke dynamic improvements (including deferred merge to indy only)
* stream-based replacements for XmlSlurper et al
* groovydoc rework (assuming we manage to finish porting the current groovydoc to 3)
* improved built-in type checking extensions (@NonNull et al)

I am wondering if there would be receptiveness to adding streaming based versions of Groovy's standard collection methods. ie: currently

foo.collect { it * 2 }.grep { it > 10 }.take(3)

fully evaluates the collect, then fully evaluates the grep, finally only to take 3 results. Java streams now solves this as do other languages (python generators, etc), but in Groovy you have to abandon the "groovy" methods and use Java streams (which works somewhat).

I could imagine this could be done just by adding 's' to all the methods:

foo.collects { it * 2 }.greps { it > 10 }.takes(3)

Of course people might find that a bit ugly and there could be different syntaxes or solutions .... but it would be really nice to have this "natively" in Groovy!

Cheers,

Simon




 

MG
Reply | Threaded
Open this post in threaded view
|

NV macro status ?

MG
In reply to this post by paulk_asert
Hi Paul,

come to think of it, what is the status of e.g. the "named variable"
macro functionality I did a spike for - do we already have a place where
to put such macros to be delivered with Groovy ?

As a reminder, e.g. writing:

println NV(filteredEntries)

would be Groovy-macro-transformed during compilation to

println "filteredEntries=$filteredEntries"

Cheers,
mg


On 24/05/2019 02:27, Paul King wrote:

>
> Hi everyone,
>
> I plan to do a beta-2 of 3.0.0 in a few weeks and then hopefully we'll
> start the ramp down to final with one or more RCs. When we get to the
> RCs stage, I'll make a 3_0_X branch. At this stage I don't foresee a
> 3.1 version but we can certainly do one if desired/needed. So, I'll
> make master Groovy 4 at that point.
>
> What do people think about changing our maven coordinates with Groovy
> 4 from org.codehaus.groovy to org.apache.groovy?
>
> Also, if you have anything you'd particularly like to see in Groovy 4,
> please discuss. I'll have a slide on potential things in Groovy 4 in
> my gr8conf talk next week. I'd like to include as many sensible ideas
> as possible to make use of the opportunity to garner feedback on what
> our users are looking for.
>
> Some of the things currently on my list:
> * improved module support (including split package final steps)
> * further invoke dynamic improvements (including deferred merge to
> indy only)
> * stream-based replacements for XmlSlurper et al
> * groovydoc rework (assuming we manage to finish porting the current
> groovydoc to 3)
> * improved built-in type checking extensions (@NonNull et al)
>
> Let me know what is on your lists of things you'd like to see.
>
> Cheers, Paul.
>

12