That would be very nice to have. Sent from my iPhone
> -- Clark Richey CHIEF TECHNOLOGY OFFICER 240.252.7507 cl...@factgem.com WWW.FACTGEM.COM This message and any included attachments are property of FactGem and its affiliates, and are intended only for the addressee(s). The information contained herein may include trade secrets or privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you received this message in error, or have reason to believe you are not authorized to receive it, please promptly delete this message and notify the sender by e-mail. Thank you. On Jan 29, 2016, at 03:25, Guillaume Laforge <glafo...@gmail.com> wrote: > > The other big item we had envisioned for Groovy 3 were the rewrite of > the grammar to Antlr v4, so as to support Java 8 language constructs. > >> On Fri, Jan 29, 2016 at 3:13 AM, Jochen Theodorou <blackd...@gmx.org> wrote: >> >> >>> On 29.01.2016 00:16, Edinson E. Padrón U. wrote: >>> >>> Hi, Guillaume. >>> >>> In my very humble opinion (and it should be noticed that I'm very far >>> away to know the Groovy community and language internals as well as you >>> do), the Python 2.x vs 3.x 'war' was due to mainly a very slow adoption >>> of the 3.x branch from the different third-party libraries. Even though >>> the 3.x branch is far better than its predecessor, the community stuck >>> with the 2.x branch because of the incompatibility of the libraries >>> their depended on. >> >> >> I wish you had any idea about how many projects did still use Groovy 1.8 a >> year ago. It required a CVE for them to even consider changing. >> >> [...] >>> >>> Jigsaw is inevitable and that for itself >>> require to break backward compatibility. >> >> >> yes and no.. no, because this does not *require* a new MOP, which is all >> Groovy3 originally was about. Yes, there will be breaking changes... our >> extension methods will for example have to use proper service provider >> mechanism, our modules may have to move a few classes because of the >> almighty no same package for two modules paradigm - just to just name two >> random items. It would be a good chance though to introduce a new MOP... >> here I agree. >> >> bye Jochen > > > > -- > Guillaume Laforge > Apache Groovy committer & PMC member > Product Ninja & Advocate at Restlet > > Blog: http://glaforge.appspot.com/ > Social: @glaforge / Google+
