Quantcast

Groovy 3

classic Classic list List threaded Threaded
91 messages Options
12345
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Groovy 3

Jochen Theodorou
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

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 
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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Guillaume Laforge-4
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Wujek Srujek-2
In reply to this post by Jochen Theodorou
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.



On Tue, Jun 26, 2012 at 1:17 PM, Jochen Theodorou <[hidden email]> wrote:
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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Gavin Grover
In reply to this post by Guillaume Laforge-4
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:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Guillaume Laforge-4
I'm not sure I understand the polemical you're trying to create here, as Jochen and myself are all on the same wavelength.
The MOP needs to be rewritten, if that's a clearer statement you want to hear?

On Tue, Jun 26, 2012 at 4:05 PM, Gavin Grover <[hidden email]> wrote:
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:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Mohamed Seifeddine
Is Groovy 3 going to be backwards compatible? Have Groovy been backwards compatibile so far for each release? 
Do you consider backwards compatibility to be important? 

// Moe


On Tue, Jun 26, 2012 at 5:06 PM, Guillaume Laforge <[hidden email]> wrote:
I'm not sure I understand the polemical you're trying to create here, as Jochen and myself are all on the same wavelength.
The MOP needs to be rewritten, if that's a clearer statement you want to hear?


On Tue, Jun 26, 2012 at 4:05 PM, Gavin Grover <[hidden email]> wrote:
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:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Guillaume Laforge-4
Hi Mohamed,

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).

Guillaume

On Tue, Jun 26, 2012 at 5:21 PM, Mohamed Seifeddine <[hidden email]> wrote:
Is Groovy 3 going to be backwards compatible? Have Groovy been backwards compatibile so far for each release? 
Do you consider backwards compatibility to be important? 

// Moe


On Tue, Jun 26, 2012 at 5:06 PM, Guillaume Laforge <[hidden email]> wrote:
I'm not sure I understand the polemical you're trying to create here, as Jochen and myself are all on the same wavelength.
The MOP needs to be rewritten, if that's a clearer statement you want to hear?


On Tue, Jun 26, 2012 at 4:05 PM, Gavin Grover <[hidden email]> wrote:
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:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one




--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Wujek Srujek-2
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.

wujek

On Tue, Jun 26, 2012 at 5:26 PM, Guillaume Laforge <[hidden email]> wrote:
Hi Mohamed,

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).

Guillaume


On Tue, Jun 26, 2012 at 5:21 PM, Mohamed Seifeddine <[hidden email]> wrote:
Is Groovy 3 going to be backwards compatible? Have Groovy been backwards compatibile so far for each release? 
Do you consider backwards compatibility to be important? 

// Moe


On Tue, Jun 26, 2012 at 5:06 PM, Guillaume Laforge <[hidden email]> wrote:
I'm not sure I understand the polemical you're trying to create here, as Jochen and myself are all on the same wavelength.
The MOP needs to be rewritten, if that's a clearer statement you want to hear?


On Tue, Jun 26, 2012 at 4:05 PM, Gavin Grover <[hidden email]> wrote:
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:

   http://xircles.codehaus.org/manage_email





--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one




--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Jochen Theodorou
In reply to this post by Gavin Grover
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:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Jochen Theodorou
In reply to this post by Wujek Srujek-2
Am 26.06.2012 18:35, schrieb Wujek Srujek:
> 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'

hehe, yes, I think it is point 1 of the things to be changed and removed
in Groovy 3 in the linked wiki page ;)

[...]

> 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).

I see overlap with http://jira.codehaus.org/browse/GROOVY-3520 here...
And you would scrap the old optional parameters logic for that? I dare
you to make a GEP for this ;)
Surely overriding methods would get more difficult and the user
experience from Java would get lower.

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

Not all about that, but yes, I am thinking of getting rid of this stuff.

> 4. I would like to be able to use a category that I instantiate myself:
>
> use(new MyCategory('with arguments')) {
>      //
> }

you mean a category that operates on an instance?

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

and how far should the change minimally reach for your use case? only
the block or beyond?

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

thanks, good to hear ;)

bye blackdrag

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Groovy 3

Ske ptic
In reply to this post by Jochen Theodorou

I know it probably won't change with Groovy 3, but I hate to have to do :

assert map != null

instead of 

assert map 

because an empty map (or any other collection or boolean references) will fail the latter.

BTW, if there is a better alternative, let me know !

> Date: Tue, 26 Jun 2012 13:17:03 +0200

> From: [hidden email]
> To: [hidden email]
> 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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Wujek Srujek-2
In reply to this post by Jochen Theodorou

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).

I see overlap with http://jira.codehaus.org/browse/GROOVY-3520 here... And you would scrap the old optional parameters logic for that? I dare you to make a GEP for this ;)
Surely overriding methods would get more difficult and the user experience from Java would get lower.

I am not sure, the issue still mangles Mas.
Why do you think this would make overriding more difficult, and Java interop worse? I think that calling Java methods from Groovy just has to use positional parameters (I don't think I can succesfully use the Map workaround that exists now? the java method would need to take a Map, and I don't know if it would work anyways, just like POJO setProperty doesn't work). What about overriding? When a method is overridden, you generate its own @Params and value classes, not overridden methods use the old ones. The problem might arise when you override and change the param names, and don't know the runtime type (have a reference to the superclass but actually a subclass is used), which is one of the edge cases I mentioned (but scala / ceylon do manage to get it working) - there could be a restriction that you can't change the names or sth, but this seems stupid.
 

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

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

you mean a category that operates on an instance?

Yes. The added methods are instance methods (not static) that take self as the first argument. My use case: we had a DSL that could evaluate 'paths' against objects via Unified EL (pimped a lot and extended). The type of the object doesn't matter as long as there are correct resolvers (that's the standard way in EL, which is a standard part of Java EE). We had a Java engine that takes a path, the root, and returns value(s). I wanted to have it so I can take the instance that I get into the script (I don't know the type, neither do I need to, as far as I know it's just 'something'), and call a method on it, which uses the engine inside. Normally, in Java, you use the engine like this:
engine.evaluate(root, 'some.path')
In groovy I wanted:
root.'some.path'
where I use methodMissing for the 'some.path' part. I did it with messing around with the metaClass, but that adds the methods for ever (for the current groovy), whereas after the evaluation (like further in the process) I would like the method to disappear and not leave trace. As far as I know, there is no clear way to remove a method from a metaClass, you can only set it to something else (like sth that throws an exception), but that's not clean, imho. BTW, maybe this could be in the new MOP as well?
The engine gets passed to the groovy process as a script binding, as it is a pretty expensive thing to create. I want / need to use our DI framework (CDI) for that. It all works beautifully except for the metaClass part.

To sum up: I would like to be able to apply a category (maybe something new?) to a block of code, and I would like to be able to initialize it somehow myself with dependencies, not rely on static methods / state, and that I can use to add methodMissing to classes.


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.

and how far should the change minimally reach for your use case? only the block or beyond?

The block. The code that is inside (which might be a call to GroovyScriptEngine recursively, as the scripts might call evaluate() and others) or deeply nested methods should see the changes. Mind that such use blocks might be called by multiple threads, so static state is not really an option (unless you mess around with ThreadLocals...).

wujek
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Groovy 3

Bob Brown
My bugbears:

1. I'd like to see a version of Ruby's case statement:

def manufacturer = match(car) {
  when "Focus",     "Ford"
  when "Navigator", "Lincoln"
  when "Camry",     "Toyota"
  when "Civic",     "Honda"
  when "Patriot",   "Jeep"
  when "Jetta",     "VW"
  when "Ceyene",    "Porsche"
  when "Outback",   "Subaru"
  when "520i",      "BMW"
  when "Tundra",    "Nissan"
  otherwise         "Unknown"
}

This construct is incredibly useful (converting to/from database-y stuff,
for example). I probably need it once a day (and I DO know about the various
facilities provided in enums).

I remember having a nice discussion about this with Guillame Laforge and
subsequently wrote this up (there's more):
http://wordpress.transentia.com.au/wordpress/2009/03/11/inventing-a-new-stat
ement-for-groovy-in-10-minutes/.

I also recall having a discussion with Paul King about this....trying to
create an AST transform, but we couldn't quite get there. It needs to be in
the language.

2. I'd like to:

println "An error occurred on ${__LINE__} of ${__FILE__}"

3. I'd like a facility analogous to bash's xtrace option:

bash -x command.sh

These latter two hark back to the idea of "Groovy as scripting tool", rather
than "Groovy as programming language" and are more pie-in-the sky and MUCH
harder to do for Groovy than for bash, of course. But you guys DID ask ;-)

Cheers.

BOB


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Groovy 3

Bob Brown
With respect to the cumbersome nature of:

println a?.b?.c?.e?.f

I dimly recall another discussion around this a while back. I seem to
remember people considering:

println a??.b.c.d.e.f

as a useful shortcut syntax.

The compiler would generate something like:

def tmp = a
tmp = tmp ? tmp.a : null
tmp = tmp ? tmp.b : null
tmp = tmp ? tmp.c : null
tmp = tmp ? tmp.d : null
tmp = tmp ? tmp.e : null
if (tmp) tmp =tmp.f

Can't find anything to support my lousy memory, though...

Cheers,

Bob


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Gavin Grover
In reply to this post by Jochen Theodorou
Jochen,

Part of the roadmapped semantic changes in Groovy 3 is the Java 8 closure retrofit. The Java 8 closures will add many methods to the java standard libraries, see http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html

Their methods duplicate many Groovy methods in the GDK, though their names are different, e.g. forEach, filter, into, map, flatMap, pipeline, sorted, groupByMulti, reduce, anyMatch.

Will this mean Groovy 3 will deprecate most of the core GDK methods in favor of the Java 8 new closure methods?

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Wujek Srujek-2
In reply to this post by Bob Brown


On Wed, Jun 27, 2012 at 12:50 AM, Bob Brown <[hidden email]> wrote:
My bugbears:

1. I'd like to see a version of Ruby's case statement:

def manufacturer = match(car) {
 when "Focus",     "Ford"
 when "Navigator", "Lincoln"
 when "Camry",     "Toyota"
 when "Civic",     "Honda"
 when "Patriot",   "Jeep"
 when "Jetta",     "VW"
 when "Ceyene",    "Porsche"
 when "Outback",   "Subaru"
 when "520i",      "BMW"
 when "Tundra",    "Nissan"
 otherwise         "Unknown"
}

What do you need here that you can't do with Groovy switch?

wujek
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Groovy 3

Bob Brown
This is the discussion I had before...

One CAN do it all with a switch. It's more cumbersome but it can be done.

Of course.

And I discussed this/how at the link I gave before...

Here's a tiny bit of 'real' code from a project:

  private textColor(s) {
    match(s)
      case CUSTOMER: return "#00FF00"; break;
      case SYSTEM: return "#FF0000"; break;
      case ADMIN: return "#0000FF"; break;
    }
  }

To me, the following expresses what I need much more cleanly:

  private textColor(s) {
    match (s) {
      when CUSTOMER,  "#00FF00"
      when SYSTEM, "#FF0000"
      when ADMIN, "#0000FF"
    }
  }

Now: a 'switch' isn't 'necessary' because we have an 'if' statement, and a
safe navigator operator isn't required because an 'if' will "do the job",
and a 'while' isn't needed if you have a 'for' loop, etc.

I think the point isn't necessity, but lack of ceremony/ease of use/fun call
it what you will.

I recall a previous colleague dismissing C because he could do it all in
BCPL ;-)

I am also thinking of a "South Park" episode: "simpsons already did it"
(http://en.wikipedia.org/wiki/Simpsons_Already_Did_It) in this case "ruby
already did it", although you may feel that this is not good enough reason.

Cheers,

BOB

> -----Original Message-----
> From: Wujek Srujek [mailto:[hidden email]]
> Sent: Wednesday, 27 June 2012 3:35 PM
> To: [hidden email]
> Subject: Re: [groovy-user] Groovy 3
>
>
>
> On Wed, Jun 27, 2012 at 12:50 AM, Bob Brown <[hidden email]>
> wrote:
>
>
> My bugbears:
>
> 1. I'd like to see a version of Ruby's case statement:
>
> def manufacturer = match(car) {
> when "Focus",     "Ford"
> when "Navigator", "Lincoln"
> when "Camry",     "Toyota"
> when "Civic",     "Honda"
> when "Patriot",   "Jeep"
> when "Jetta",     "VW"
> when "Ceyene",    "Porsche"
> when "Outback",   "Subaru"
> when "520i",      "BMW"
> when "Tundra",    "Nissan"
> otherwise         "Unknown"
> }
>
>
>
> What do you need here that you can't do with Groovy switch?
>
> wujek


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Jochen Theodorou
In reply to this post by Wujek Srujek-2
Am 26.06.2012 16:02, schrieb Wujek Srujek:
> 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.

This is going to be a standard case with the new MOP, so this will
ensured to work ;)

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

yes, well, this is due to them being called directly through Java. I
mean to change that (along with having them not there anymore by
default), so it should then work as well

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Groovy 3

Jochen Theodorou
In reply to this post by Wujek Srujek-2
Am 26.06.2012 20:01, schrieb Wujek Srujek:
[...]
> Why do you think this would make overriding more difficult, and Java
> interop worse?

currently if you do

def foo(int a=1, long b=2)

we create the methods

foo(int,long)
foo(int)
foo()

there is a strict right to left rule for this and you cannot have
foo(long) this way. We do it like this to avoid type problems since a
method signatrue can appear only once.

With optional arguments like I think you described there would be only
one method. So the optional nature is not available from Java directly.
That's why less interop. Also if you then write in a subclass for
example foo(long), does it override foo(int a=1, long b=2) in some cases
or not? That's why more difficult... in this more difficult for the
compiler and the human.

> I think that calling Java methods from Groovy just has to
> use positional parameters (I don't think I can succesfully use the Map
> workaround that exists now? the java method would need to take a Map,
> and I don't know if it would work anyways, just like POJO setProperty
> doesn't work).

Of course that works. But interoperability means in Groovy we have to
include the Java world. That means we have to additionally look at the
usage from Java as well as what happens if we subclass in Java and use
from Groovy. and there is such a subclassing problem with only named
arguments as well here... Assume:

class X {
   def foo(int a, int b){}
}
....
def x = getInstanceFromSomewhere()
x.foo(b=1,a=2)

and assume the getInstanceFromSomewhere() does not return an X, but an Y
extends X, written in Java, thus without named parameters. That means
this call x.foo above would work only if the returned Object is an X, as
soon as it is an Y it will not work anymore.

[...]

> To sum up: I would like to be able to apply a category (maybe something
> new?) to a block of code, and I would like to be able to initialize it
> somehow myself with dependencies, not rely on static methods / state,
> and that I can use to add methodMissing to classes.
>
>
>         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.
>
>
>     and how far should the change minimally reach for your use case?
>     only the block or beyond?
>
>
> The block. The code that is inside (which might be a call to
> GroovyScriptEngine recursively, as the scripts might call evaluate() and
> others) or deeply nested methods should see the changes. Mind that such
> use blocks might be called by multiple threads, so static state is not
> really an option (unless you mess around with ThreadLocals...).

categories currently are ThreadLocal changes, visible along the stack.
This has been a problem in the past, because of the way we checked our
callsites for validity. But now I know how to prevent this. So the only
thing that is going to be slower is the method selection part and
entering the block. Imho it should not really be a problem to use an
instance here

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


12345
Loading...