Groovy 3

Groovy 3

Hi all,

soon Groovy 2 will be released and I will start on working for Groovy 3,
which is supposed to get released next year. Groovy 3 will contain a new
MOP and some semantic changes. I thought I start a GEP (GEP-11) for this
to make it more easy for people to contribute. I only just started the
with some things I want not to have anymore in Groovy3. I will soon try
to describe the new MOP. But most probably that will be in constant
flux, since I will have to see if things work out right or not while I
implement it.

So anyone who wants something absolutely in Groovy3 regarding semantics
or the new MOP.. it would be a good time to speak now... for example in
this thread. I will collect the ideas on the wiki page of the GEP and
possibly make them part of that "design document".

Those who want some syntactic changes, sorry, they will not be part of
that GEP.

> From: Jochen Theodorou <[hidden email]>
> To: [hidden email]> Cc:
> Sent: Tuesday, June 26, 2012 7:17 PM
> Subject: [groovy-user] Groovy 3
>
> Hi all,
>
> soon Groovy 2 will be released and I will start on working for Groovy 3, which
> is supposed to get released next year. Groovy 3 will contain a new MOP and some
> semantic changes. I thought I start a GEP (GEP-11) for this to make it more easy
> for people to contribute. I only just started the with some things I want not to
> have anymore in Groovy3. I will soon try to describe the new MOP. But most
> probably that will be in constant flux, since I will have to see if things work
> out right or not while I implement it.
>
> So anyone who wants something absolutely in Groovy3 regarding semantics or the
> new MOP.. it would be a good time to speak now... for example in this thread. I
> will collect the ideas on the wiki page of the GEP and possibly make them part
> of that "design document".
>
> Those who want some syntactic changes, sorry, they will not be part of that GEP.
>
> @see
> http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP>
> bye blackdrag
>
> -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

Re: Groovy 3

The mail you refer to has nothing to do with the current discussion. It was about a terminology aspect, where it might be confusing for users if we tell them Groovy "closures" aren't "closures" or should change name.

Here we speak about moving Groovy forward, fixing odd corner cases of the language and APIs, making the MOP more efficient, saner, etc.

----- Original Message -----
> From: Jochen Theodorou <[hidden email]>
> To: [hidden email]
> Cc:
> Sent: Tuesday, June 26, 2012 7:17 PM
> Subject: [groovy-user] Groovy 3
>
> Hi all,
>
> soon Groovy 2 will be released and I will start on working for Groovy 3, which
> is supposed to get released next year. Groovy 3 will contain a new MOP and some
> semantic changes. I thought I start a GEP (GEP-11) for this to make it more easy
> for people to contribute. I only just started the with some things I want not to
> have anymore in Groovy3. I will soon try to describe the new MOP. But most
> probably that will be in constant flux, since I will have to see if things work
> out right or not while I implement it.
>
> So anyone who wants something absolutely in Groovy3 regarding semantics or the
> new MOP.. it would be a good time to speak now... for example in this thread. I
> will collect the ideas on the wiki page of the GEP and possibly make them part
> of that "design document".
>
> Those who want some syntactic changes, sorry, they will not be part of that GEP.
>
> @see
> http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP
>
> bye blackdrag
>
> -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

Re: Groovy 3

There was something about methodMissing (or maybe it was getProperty et.al.?) not being able to be defined with a closure assignment to a metaClass.

Then, I had this case that my Java class had get/setProperty methods, but they were not discovered by Groovy, and so I had to set get/setProperty closures to the metaClass, which just called the Java methods.

soon Groovy 2 will be released and I will start on working for Groovy 3, which is supposed to get released next year. Groovy 3 will contain a new MOP and some semantic changes. I thought I start a GEP (GEP-11) for this to make it more easy for people to contribute. I only just started the with some things I want not to have anymore in Groovy3. I will soon try to describe the new MOP. But most probably that will be in constant flux, since I will have to see if things work out right or not while I implement it.

So anyone who wants something absolutely in Groovy3 regarding semantics or the new MOP.. it would be a good time to speak now... for example in this thread. I will collect the ideas on the wiki page of the GEP and possibly make them part of that "design document".

Those who want some syntactic changes, sorry, they will not be part of that GEP.

Re: Groovy 3

The rest of the referred thread, a discussion between Russel and Jochen, is another semantic change that some might want in GEP-11, and has everything to do with the current discussion.

I was questioning whether the discussion will amount to any action if Jochen is writing "Groovy 3 will contain a new MOP" below, but you're writing "moving Groovy forward, [...] making the MOP more efficient, saner, etc."

Gavin Grover

>________________________________
> From: Guillaume Laforge <[hidden email]>
>To: [hidden email]>Sent: Tuesday, June 26, 2012 9:14 PM
>Subject: Re: [groovy-user] Groovy 3
>
>
>The mail you refer to has nothing to do with the current discussion. It was about a terminology aspect, where it might be confusing for users if we tell them Groovy "closures" aren't "closures" or should change name.
>Here we speak about moving Groovy forward, fixing odd corner cases of the language and APIs, making the MOP more efficient, saner, etc.
>
>
>
>On Tue, Jun 26, 2012 at 2:56 PM, Gavin Grover <[hidden email]> wrote:
>
>Jochen,
>>
>>will VMWare assign the budget for you to make semantic changes to Groovy and upgrade the MOP? The project management don't seem to want to change anything
>>e.g. the reply at http://groovy.329449.n5.nabble.com/Closures-closures-and-lambda-functions-tt5573493.html#a5573628>>
>>Gavin Grover
>>blog: http://groovy.codeplex.com/wikipage?title=Blog02>> email: [hidden email]>>
>>
>>
>>
>>----- Original Message -----
>>> From: Jochen Theodorou <[hidden email]>
>>> To: [hidden email]>>> Cc:
>>> Sent: Tuesday, June 26, 2012 7:17 PM
>>> Subject: [groovy-user] Groovy 3
>>>
>>> Hi all,
>>>
>>> soon Groovy 2 will be released and I will start on working for Groovy 3, which
>>> is supposed to get released next year. Groovy 3 will contain a new MOP and some
>>> semantic changes. I thought I start a GEP (GEP-11) for this to make it more easy
>>> for people to contribute. I only just started the with some things I want not to
>>> have anymore in Groovy3. I will soon try to describe the new MOP. But most
>>> probably that will be in constant flux, since I will have to see if things work
>>> out right or not while I implement it.
>>>
>>> So anyone who wants something absolutely in Groovy3 regarding semantics or the
>>> new MOP.. it would be a good time to speak now... for example in this thread. I
>>> will collect the ideas on the wiki page of the GEP and possibly make them part
>>> of that "design document".
>>>
>>> Those who want some syntactic changes, sorry, they will not be part of that GEP.
>>>
>>> @see
>>> http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP>>>
>>> bye blackdrag
>>>
>>> -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>>> blog: http://blackdragsview.blogspot.com/>>> german groovy discussion newsgroup: de.comp.lang.misc
>>> For Groovy programming sources visit http://groovy-lang.org>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email>>
>>
>>
>
>
>
>--
>Guillaume Laforge
>Groovy Project Manager
>Head of Groovy Development at SpringSource
>http://www.springsource.com/g2one>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

The rest of the referred thread, a discussion between Russel and Jochen, is another semantic change that some might want in GEP-11, and has everything to do with the current discussion.

I was questioning whether the discussion will amount to any action if Jochen is writing "Groovy 3 will contain a new MOP" below, but you're writing "moving Groovy forward, [...] making the MOP more efficient, saner, etc."

>
>
>The mail you refer to has nothing to do with the current discussion. It was about a terminology aspect, where it might be confusing for users if we tell them Groovy "closures" aren't "closures" or should change name.
>Here we speak about moving Groovy forward, fixing odd corner cases of the language and APIs, making the MOP more efficient, saner, etc.
>
>
>
>On Tue, Jun 26, 2012 at 2:56 PM, Gavin Grover <[hidden email]> wrote:
>
>Jochen,
>>
>>will VMWare assign the budget for you to make semantic changes to Groovy and upgrade the MOP? The project management don't seem to want to change anything
>>e.g. the reply at http://groovy.329449.n5.nabble.com/Closures-closures-and-lambda-functions-tt5573493.html#a5573628
>>
>>Gavin Grover
>>blog: http://groovy.codeplex.com/wikipage?title=Blog02
>> email: [hidden email]
>>
>>
>>
>>
>>----- Original Message -----
>>> From: Jochen Theodorou <[hidden email]>
>>> To: [hidden email]
>>> Cc:
>>> Sent: Tuesday, June 26, 2012 7:17 PM
>>> Subject: [groovy-user] Groovy 3
>>>
>>> Hi all,
>>>
>>> soon Groovy 2 will be released and I will start on working for Groovy 3, which
>>> is supposed to get released next year. Groovy 3 will contain a new MOP and some
>>> semantic changes. I thought I start a GEP (GEP-11) for this to make it more easy
>>> for people to contribute. I only just started the with some things I want not to
>>> have anymore in Groovy3. I will soon try to describe the new MOP. But most
>>> probably that will be in constant flux, since I will have to see if things work
>>> out right or not while I implement it.
>>>
>>> So anyone who wants something absolutely in Groovy3 regarding semantics or the
>>> new MOP.. it would be a good time to speak now... for example in this thread. I
>>> will collect the ideas on the wiki page of the GEP and possibly make them part
>>> of that "design document".
>>>
>>> Those who want some syntactic changes, sorry, they will not be part of that GEP.
>>>
>>> @see
>>> http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP
>>>
>>> bye blackdrag
>>>
>>> -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>>> blog: http://blackdragsview.blogspot.com/
>>> german groovy discussion newsgroup: de.comp.lang.misc
>>> For Groovy programming sources visit http://groovy-lang.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
>--
>Guillaume Laforge
>Groovy Project Manager
>Head of Groovy Development at SpringSource
>http://www.springsource.com/g2one
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

The rest of the referred thread, a discussion between Russel and Jochen, is another semantic change that some might want in GEP-11, and has everything to do with the current discussion.

I was questioning whether the discussion will amount to any action if Jochen is writing "Groovy 3 will contain a new MOP" below, but you're writing "moving Groovy forward, [...] making the MOP more efficient, saner, etc."

>
>
>The mail you refer to has nothing to do with the current discussion. It was about a terminology aspect, where it might be confusing for users if we tell them Groovy "closures" aren't "closures" or should change name.
>Here we speak about moving Groovy forward, fixing odd corner cases of the language and APIs, making the MOP more efficient, saner, etc.
>
>
>
>On Tue, Jun 26, 2012 at 2:56 PM, Gavin Grover <[hidden email]> wrote:
>
>Jochen,
>>
>>will VMWare assign the budget for you to make semantic changes to Groovy and upgrade the MOP? The project management don't seem to want to change anything
>>e.g. the reply at http://groovy.329449.n5.nabble.com/Closures-closures-and-lambda-functions-tt5573493.html#a5573628
>>
>>Gavin Grover
>>blog: http://groovy.codeplex.com/wikipage?title=Blog02
>> email: [hidden email]
>>
>>
>>
>>
>>----- Original Message -----
>>> From: Jochen Theodorou <[hidden email]>
>>> To: [hidden email]
>>> Cc:
>>> Sent: Tuesday, June 26, 2012 7:17 PM
>>> Subject: [groovy-user] Groovy 3
>>>
>>> Hi all,
>>>
>>> soon Groovy 2 will be released and I will start on working for Groovy 3, which
>>> is supposed to get released next year. Groovy 3 will contain a new MOP and some
>>> semantic changes. I thought I start a GEP (GEP-11) for this to make it more easy
>>> for people to contribute. I only just started the with some things I want not to
>>> have anymore in Groovy3. I will soon try to describe the new MOP. But most
>>> probably that will be in constant flux, since I will have to see if things work
>>> out right or not while I implement it.
>>>
>>> So anyone who wants something absolutely in Groovy3 regarding semantics or the
>>> new MOP.. it would be a good time to speak now... for example in this thread. I
>>> will collect the ideas on the wiki page of the GEP and possibly make them part
>>> of that "design document".
>>>
>>> Those who want some syntactic changes, sorry, they will not be part of that GEP.
>>>
>>> @see
>>> http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP
>>>
>>> bye blackdrag
>>>
>>> -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>>> blog: http://blackdragsview.blogspot.com/
>>> german groovy discussion newsgroup: de.comp.lang.misc
>>> For Groovy programming sources visit http://groovy-lang.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
>--
>Guillaume Laforge
>Groovy Project Manager
>Head of Groovy Development at SpringSource
>http://www.springsource.com/g2one
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

Re: Groovy 3

We've always tried to stay backward-compatible as much as possible, but there has been a few compatibility issues between certain versions.

Sometimes on purpose to fix issues, and a few times non desired.

But Groovy 3 will not be fully backward compatible, most probably around the usage of the runtime metaprogramming techniques, plus the various bits of semantic we want to fix (some of them already listed by Jochen on the linked page).

The rest of the referred thread, a discussion between Russel and Jochen, is another semantic change that some might want in GEP-11, and has everything to do with the current discussion.

I was questioning whether the discussion will amount to any action if Jochen is writing "Groovy 3 will contain a new MOP" below, but you're writing "moving Groovy forward, [...] making the MOP more efficient, saner, etc."

>
>
>The mail you refer to has nothing to do with the current discussion. It was about a terminology aspect, where it might be confusing for users if we tell them Groovy "closures" aren't "closures" or should change name.
>Here we speak about moving Groovy forward, fixing odd corner cases of the language and APIs, making the MOP more efficient, saner, etc.
>
>
>
>On Tue, Jun 26, 2012 at 2:56 PM, Gavin Grover <[hidden email]> wrote:
>
>Jochen,
>>
>>will VMWare assign the budget for you to make semantic changes to Groovy and upgrade the MOP? The project management don't seem to want to change anything
>>e.g. the reply at http://groovy.329449.n5.nabble.com/Closures-closures-and-lambda-functions-tt5573493.html#a5573628
>>
>>Gavin Grover
>>blog: http://groovy.codeplex.com/wikipage?title=Blog02
>> email: [hidden email]
>>
>>
>>
>>
>>----- Original Message -----
>>> From: Jochen Theodorou <[hidden email]>
>>> To: [hidden email]
>>> Cc:
>>> Sent: Tuesday, June 26, 2012 7:17 PM
>>> Subject: [groovy-user] Groovy 3
>>>
>>> Hi all,
>>>
>>> soon Groovy 2 will be released and I will start on working for Groovy 3, which
>>> is supposed to get released next year. Groovy 3 will contain a new MOP and some
>>> semantic changes. I thought I start a GEP (GEP-11) for this to make it more easy
>>> for people to contribute. I only just started the with some things I want not to
>>> have anymore in Groovy3. I will soon try to describe the new MOP. But most
>>> probably that will be in constant flux, since I will have to see if things work
>>> out right or not while I implement it.
>>>
>>> So anyone who wants something absolutely in Groovy3 regarding semantics or the
>>> new MOP.. it would be a good time to speak now... for example in this thread. I
>>> will collect the ideas on the wiki page of the GEP and possibly make them part
>>> of that "design document".
>>>
>>> Those who want some syntactic changes, sorry, they will not be part of that GEP.
>>>
>>> @see
>>> http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP
>>>
>>> bye blackdrag
>>>
>>> -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>>> blog: http://blackdragsview.blogspot.com/
>>> german groovy discussion newsgroup: de.comp.lang.misc
>>> For Groovy programming sources visit http://groovy-lang.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
>--
>Guillaume Laforge
>Groovy Project Manager
>Head of Groovy Development at SpringSource
>http://www.springsource.com/g2one
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

Re: Groovy 3

1. I found this part really confusing once, and it stole me a lot of time:

class Foo {

Foo(whatever) {

println "whatever is: $whatever"

}

}

new Foo() // prints 'whatever is: null'

I think the call should simply fail. This has something to do with another constructor being generated, that takes a map, which is empty, or maybe with the automatic method call with nulls that Jochen already mentioned on the page? All in all, I would like this one to be fixed.

2. I would really like real named parameters, not a Map. This can be achieved (the JVM doesn't support it) by changing this:

def method(a, b, c) { ... }

into

def method(@Param('a') a, @Param('b') b, @Param('c') c) { ... }

with @Param being a runtime-retained annotation. This information is then available during runtime, so a call:

method(c=1, b=2, a=3)

would trigger lookup of parameter names and call the method correctly. I believe scala / ceylon do it this way, maybe others as well. You could also add default values:

def method(a=1+2+3) { ... }

which ends up being:

def method(@Param('a', defVal=Param_a_value.class) a) { ... }

where the expression gets compiled into a class, that ges saved, and executed upon execution. The defVal must be a class now, as JVM only expects constants as annotation values, I guess, but that should work. Upon a call that doesn't define the parameter, the default value class is looked up and executed, to complement the arguments.

This is just a rough idea, which surely is not ripe and there are edge cases, but this seems doable (again, I think ceylon has the possibility to execute ordinary code for parameters).

3. I don't know if you already include that or not, but the fact that GroovyObject has getProperty and invokeMethod, but not propertyMissing and methodMissng (which are then magically used in MetaClassImpl, I think) is pure inconsistency. They should be defined by the same means. Unless you just want to get rid of this stuff ;d and the MOP change is all about that.

4. I would like to be able to use a category that I instantiate myself:

use(new MyCategory('with arguments')) {

//

}

My use case was that the category would get some arguments that I had dependency-injected into the class that had the above code. It would have made my design simpler in a few cases.

BTW, I would like to use the occasion and thank you guys for the tremendous job your are doing on implementig, supporting and pushing Groovy forward. It has become my favorite language for the JVM, I can't imagine not having it to employ it here or there for specific tasks I must do, especially DSL implementation. I also really like gradle ;d which exists thanks to Groovy.

We've always tried to stay backward-compatible as much as possible, but there has been a few compatibility issues between certain versions.

Sometimes on purpose to fix issues, and a few times non desired.

But Groovy 3 will not be fully backward compatible, most probably around the usage of the runtime metaprogramming techniques, plus the various bits of semantic we want to fix (some of them already listed by Jochen on the linked page).

The rest of the referred thread, a discussion between Russel and Jochen, is another semantic change that some might want in GEP-11, and has everything to do with the current discussion.

I was questioning whether the discussion will amount to any action if Jochen is writing "Groovy 3 will contain a new MOP" below, but you're writing "moving Groovy forward, [...] making the MOP more efficient, saner, etc."

>
>
>The mail you refer to has nothing to do with the current discussion. It was about a terminology aspect, where it might be confusing for users if we tell them Groovy "closures" aren't "closures" or should change name.
>Here we speak about moving Groovy forward, fixing odd corner cases of the language and APIs, making the MOP more efficient, saner, etc.
>
>
>
>On Tue, Jun 26, 2012 at 2:56 PM, Gavin Grover <[hidden email]> wrote:
>
>Jochen,
>>
>>will VMWare assign the budget for you to make semantic changes to Groovy and upgrade the MOP? The project management don't seem to want to change anything
>>e.g. the reply at http://groovy.329449.n5.nabble.com/Closures-closures-and-lambda-functions-tt5573493.html#a5573628
>>
>>Gavin Grover
>>blog: http://groovy.codeplex.com/wikipage?title=Blog02
>> email: [hidden email]
>>
>>
>>
>>
>>----- Original Message -----
>>> From: Jochen Theodorou <[hidden email]>
>>> To: [hidden email]
>>> Cc:
>>> Sent: Tuesday, June 26, 2012 7:17 PM
>>> Subject: [groovy-user] Groovy 3
>>>
>>> Hi all,
>>>
>>> soon Groovy 2 will be released and I will start on working for Groovy 3, which
>>> is supposed to get released next year. Groovy 3 will contain a new MOP and some
>>> semantic changes. I thought I start a GEP (GEP-11) for this to make it more easy
>>> for people to contribute. I only just started the with some things I want not to
>>> have anymore in Groovy3. I will soon try to describe the new MOP. But most
>>> probably that will be in constant flux, since I will have to see if things work
>>> out right or not while I implement it.
>>>
>>> So anyone who wants something absolutely in Groovy3 regarding semantics or the
>>> new MOP.. it would be a good time to speak now... for example in this thread. I
>>> will collect the ideas on the wiki page of the GEP and possibly make them part
>>> of that "design document".
>>>
>>> Those who want some syntactic changes, sorry, they will not be part of that GEP.
>>>
>>> @see
>>> http://docs.codehaus.org/display/GroovyJSR/GEP+11+-+Groovy+3+semantics+and+new+MOP
>>>
>>> bye blackdrag
>>>
>>> -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>>> blog: http://blackdragsview.blogspot.com/
>>> german groovy discussion newsgroup: de.comp.lang.misc
>>> For Groovy programming sources visit http://groovy-lang.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
>--
>Guillaume Laforge
>Groovy Project Manager
>Head of Groovy Development at SpringSource
>http://www.springsource.com/g2one
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

Re: Groovy 3

Am 26.06.2012 14:56, schrieb Gavin Grover:
> Jochen,
>
> will VMWare assign the budget for you to make semantic changes to
> Groovy and upgrade the MOP? The project management don't seem to want
> to change anything

The project management is mainly Guillaume an myself. And we both want a
new MOP a long time now. Changing by now established terminology is of a
different beast then changing the semantics of the language a little
here and there. And even if the new MOP will not be an upgrade, but a
major changing break, most of the semantics in Groovy will still stay
the same.

Anyway... to answer your question... Vmware has no problem so far in
letting me do that new MOP and paying me for it ;)

bye Jochen

---------------------------------------------------------------------
To unsubscribe from this list, please visit: