RE: About creating instances of non-static inner classes with Java-Like syntax

[eric.milles]

I know it is part of the Java spec, but do you know anyone that actuallky does 
that?  I'm just curious as I've never once seen a need for it.

Array creation is the one item that comes up most often for me when converting 
a source file from Java to Groovy.

RE: Determining the registered DGM classes at runtime

[eric.milles]

What API can I call to get a list of modules?  I'm having trouble determining 
the actual entry point.

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Friday, April 06, 2018 1:36 PM
To: dev@groovy.apache.org
Subject: Re: Determining the registered DGM classes at runtime

On 06.04.2018 18:42, eric.mil...@thomsonreuters.com wrote:
> Is it possible to determine the available Category (aka DGM) extension 
> classes at runtime?  I have been relying on 
> DefaultGroovyMethods.DGM_LIKE_CLASSES, but this has been getting 
> reduced with each release due to modularization.  And it was never 
> really a good source to begin with.  I tried looking through 
> ExtensionModuleRegstry, but I couldn't make out a good entry point for 
> asking for the DGM classes.

you will have to build an index for this I think. You can ask for a list of 
modules and also for the available methods in each. Or you simulate the 
discovery mechanism and play it from there without instantiating any of the 
Modules

bye Jochen

Determining the registered DGM classes at runtime

[eric.milles]

Is it possible to determine the available Category (aka DGM) extension classes 
at runtime?  I have been relying on DefaultGroovyMethods.DGM_LIKE_CLASSES, but 
this has been getting reduced with each release due to modularization.  And it 
was never really a good source to begin with.  I tried looking through 
ExtensionModuleRegstry, but I couldn't make out a good entry point for asking 
for the DGM classes.  I see STC using this stuff to ask if a given method name 
is a DGM.  But this does not meet the needs of content assist, which must 
suggest all method names for a given prefix.

RE: GROOVY-8527: Enhance import aliasing to an alias with a package name

[eric.milles]

Yes, the statements I made are a bit exaggerated.  That was to bring out a 
little more discussion on balance of maintenance vs enhancement.

In my case, I am suggesting fixes because I have groovy-eclipse setup and this 
gives me a chance to make some small patches to groovy-core and see if they fix 
the problems I run into.  For me to submit a PR to groovy-core, I would need to 
get that entire project setup and get familiarized with the build and test 
cycle.  And then how would I decide how much time to spend trying to improve 
groovy-eclipse vs. groovy-core.  I felt that reporting issues and submitting 
diffs/patches would be sufficient.


Here are my top 3 from my bugs list:
GROOVY-8509 error for call to protected method from same package
GROOVY-8063 Type annotation value referencing inner class is not properly scoped
GROOVY-7975 Use of static final field in an annotation element causes compile 
errors

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Wednesday, April 04, 2018 7:37 PM
To: dev@groovy.apache.org
Subject: Re: GROOVY-8527: Enhance import aliasing to an alias with a package 
name

On 04.04.2018 21:38, eric.mil...@thomsonreuters.com wrote:
>>> [...]I have submitted over 20 bugs in the past months for existing 
>>> features that do not mix well with eachother or are not completely 
>>> implemented and yet I feel the core development thrust is not in 
>>> fixing bugs for existing features but in adding new features for the 
>>> sake of new features.
>>
>> not many are eager to spend their spare time after working hours on fixing 
>> complicated bugs and going through the whole process and discussions.
> 
> If the incentive for fixing bugs was enticing enough, wouldn't there be eager 
> developers? 

Do you have a recipe of how to give an enticing incentive? Actually, from 
looking at your issues you are suggesting solutions in some places, but you 
seem not be motivated enough to make a pull request for example. 
Why is that?

> What then is the point of adding new features onto an unhealthy, 
> under-supported language?

I think you exaggerate. But the point is attracting new people. If you do not 
move, people move away. Annoying, long standing bugs can have the same effect 
of course

>  If this is truly the state of the union, then I would vote NO on all new 
> feature development.

We need to find the right balance. The new parser for example does not exist 
because we wanted a new parser. It exists because the old parser started to 
become a problem for fixing bugs. Of course once you have a new parser, that is 
more maintainable and a person that understands it very well, you will also see 
features from other languages and see them with the eyes of a parser guy that 
is wondering if this brings any benefit to Groovy. That is natural.

Anyway... the static compiler is a deep resource of bugs and will stay being it 
a long time. Inner classes in all variants contain new surprises time over 
time. But excluding those two topics what are your top 3 of open bugs in jira 
entered by you where existing features do not mix well with eachother or are 
not completely implemented?

bye Jochen

RE: GROOVY-8527: Enhance import aliasing to an alias with a package name

[eric.milles]

>> [...]I have submitted over 20 bugs in
>> the past months for existing features that do not mix well with 
>> eachother or are not completely implemented and yet I feel the core 
>> development thrust is not in fixing bugs for existing features but in 
>> adding new features for the sake of new features.
>
> not many are eager to spend their spare time after working hours on fixing 
> complicated bugs and going through the whole process and discussions.

If the incentive for fixing bugs was enticing enough, wouldn't there be eager 
developers?  What then is the point of adding new features onto an unhealthy, 
under-supported language?  If this is truly the state of the union, then I 
would vote NO on all new feature development.

RE: GROOVY-8527: Enhance import aliasing to an alias with a package name

[eric.milles]

I agree; I don't see the value here.  Could the backwards compat problem be 
solved with compiler configuration (aka a global transform)?

I have heard from many developers that import aliasing is a feature they don't 
particularly like.  Adding an odd edge case to this feature seems confusing at 
best to me as a user of the language.  I must stress again my sentiment from a 
couple months ago: there are so many features being added witout much in the 
way of discussion that I don't see much focus in what Groovy 3.0 is intended to 
be.  I have submitted over 20 bugs in the past months for existing features 
that do not mix well with eachother or are not completely implemented and yet I 
feel the core development thrust is not in fixing bugs for existing features 
but in adding new features for the sake of new features.

From: mg [mailto:mg...@arscreat.com]
Sent: Wednesday, April 04, 2018 7:32 AM
To: dev@groovy.apache.org
Subject: Re: GROOVY-8527: Enhance import aliasing to an alias with a package 
name

Hmmm - is it really worth introducing this feature for a temporary backward 
compatibility fix, especially considering Paul himself is mentioning some 
security concerns ? Wouldn't it be better to supply e.g. a small tool that 
converts Groovy pre-module-code to Groovy 3.0 code (could CodeNarc be used for 
something like that ?), that could fix or point out different kinds of 
"breaking changes spots" ?

RE: [RFE] Methods as expressions

[eric.milles]

I think you could experiment with this using a closure, since return statements 
have this expression property already:

final foo = ({ ->
  if(...) { ... }
  else if(...) { ... }
  else if(...) { ... }
  else { ... }
}())


From: mg [mailto:mg...@arscreat.com]
Sent: Wednesday, March 21, 2018 4:03 PM
To: dev@groovy.apache.org
Subject: Re: [RFE] Methods as expressions

Having control flow statements as expressions in Groovy would feel pretty 
natural to me. I had always assumed there were reasons why this was not 
supported, so I did not bring it up...
I currently use the simulated eval language extension I proposed for that, i.e.

final foo = eval {
  if(...) { ... }
  else if(...) { ... }
  else if(...) { ... }
  else { ... }
}

in cases where using "?" would be too complex.

That uses a closure, of course, so not optimal for all applications.

Question: Does a return-statement inside the if-expression leave the 
expression, or the enclosing method in Rust ?

RE: [RFE] Methods as expressions

[eric.milles]

Java syntax for a default method value is:
public @interface Delegate {
boolean interfaces() default true;


Is there really a need to introduce another form when the saving is actially 0 
characters (colon and equals vs open and close brace)?

class Foo {
fun truth(): Integer = 42
}
  vs.
class Foo {
Integer truth() { 42 }
}


What about the difference in named parameters in annotations vs. methods?

@Anno(name = value)
def foo = bar(name: value)

Could the map-entry syntax be supported for annotations to normalize named 
parameters?

From: mg [mailto:mg...@arscreat.com]
Sent: Tuesday, March 20, 2018 7:11 AM
To: dev@groovy.apache.org
Subject: Re: [RFE] Methods as expressions

I agree with the proper functions in principle, but in this case it  would be 
"special syntax for a special, limited case" which to me is the (non desirable) 
C# way of doing things...
In any case it would imho be good to see what actually comes out of Java in 
this regard, instead of making Groovy Kotlin compatible now


 Ursprüngliche Nachricht 
Von: David Dawson 
>
Datum: 20.03.18 13:00 (GMT+01:00)
An: dev@groovy.apache.org
Betreff: Re: [RFE] Methods as expressions

I personally agree with Cedric, having the intent of "proper" functions would 
be useful. Perhaps the = could be replaced, but I certainly like the idea of 
having more expression oriented syntax in Groovy.
Java itself seems to be moving in this direction with the proposed switch 
expression syntax?  This feels very similar?


On 20 March 2018 at 11:39, mg > 
wrote:
@style rules: Then change your style rules to allow single line single 
statement blocks, do not change the language, no ?-)

 Ursprüngliche Nachricht 
Von: Cédric Champeau 
>
Datum: 20.03.18 12:23 (GMT+01:00)
An: dev@groovy.apache.org
Betreff: Re: [RFE] Methods as expressions

Again that's a declaration of intent (if you put apart the fact that you can 
have style rules that force you to put the brackets on new lines).
When I write:
double surface(double x, double y) = x * y
It's very clear what the intent of this is. It's an expression, a _function_. 
On the other hand, { ... } declares a block, that could represent an 
expression, or a statement, or a list of statements, one of them returning an 
expression. I like the declaration of intent.

2018-03-20 12:20 GMT+01:00 mg >:
Am having a migraine right now so hard to concentrate / think straight but it 
seems all that syntax does is getting rid of a single character ?

Integer truth() { 42 }

could then be written as

Integer truth() = 42


or

String hello(String name) { "Hello $name" }

String hello(String name) = Hello $name"

(why did you use a return keyword in your sample ?)

I dont see an improvement in readability here - the main "advantage" is that 
curly braces are annoying to input on non-US keyboard layouts ;-)

mg



 Ursprüngliche Nachricht 
Von: Cédric Champeau 
>
Datum: 20.03.18 11:41 (GMT+01:00)
An: dev@groovy.apache.org
Betreff: [RFE] Methods as expressions

Hi,
One of the Kotlin features I really like is the short-hand notation for simple 
expression methods:

class Foo {
fun truth(): Integer = 42
}

For example, in Groovy, you write:



@Controller("/") class HelloController {

@Get("/hello/{name}")
String hello(String name) {
return "Hello $name"
}
}

but we could write:



@Controller("/")
class HelloController {
@Get("/hello/{name}")
String hello(String name) = "Hello $name"
}

It's more concise and makes the "functional style" more readable. Is this 
something Groovy users would appreciate?

RE: Parrot Parser: AST position information

[eric.milles]

Sorry, yes Eclipse adds those.  I wasn't aware the patching began at such a low 
level.  It would be nice to have the option of getting an offset instead of 
line,column.  But I can't see an easy path to that.

-Original Message-
From: Daniel Sun [mailto:realblue...@hotmail.com] 
Sent: Monday, March 12, 2018 6:51 PM
To: d...@groovy.incubator.apache.org
Subject: Re: Parrot Parser: AST position information

Hi Eric,

   Parrot will set node position of `ASTNode`, i.e. `lineNumber`, 
`columnNumber`, `lastLineNumber`, `lastColumnNumber`. As for `start`, `end`, 
`nameStart` and `nameEnd`,  I can not find them in the Apache Groovy project. 
Can you tell me which class contains them?

Cheers,
Daniel.Sun= 

Parrot Parser: AST position information

[eric.milles]

I just gave the Parrot Parser a quick try out for Groovy 2.6 / Eclipse 4.8.  
One thing I'm noticing right away is that the parser sets the line and column 
information of AST nodes, but leaves position properties start, end, nameStart 
and nameEnd unset.  Is there a way to request these properties get set?  Or is 
there an available line,col -> offset function somewhere?

Eric Milles
Lead Software Engineer
Thomson Reuters
Email: eric.mil...@thomsonreuters.com
Phone: 651-848-7040

GROOVY-5306 (?= operator)

[eric.milles]

GROOVY-5306 (https://issues.apache.org/jira/browse/GROOVY-5306) states:

Add "a ?= 2" support: should be expanded to "a = a == null ? 2 : a"

Shouldn't the expansion be "a = (a != null ? a : 2)"?  Like other ternary 
situations, the alternative would not be evaluated unless needed.  Also, is it 
a null check and not Groovy truth in the condition?

If "a" is not null in this example, does the bytecode actually execute an 
assignment?  That seems unnecessary as well.

Groovy 2.5.0-beta-3 feedback

[eric.milles]

A couple notes on Groovy 2.5b3:

1) The groovy-2.5.0-beta-3-sources.jar on Maven Central has a lot of duplicate 
source entries; at least under the groovy packages.

2) I'm having a little trouble with the new PropertyHandler stuff that supports 
@Immutable.  The error "The propertyHandler class 
'groovy.transform.options.ImmutablePropertyHandler' on @MapConstructor  is not 
a propertyHandler" is showing anywhere @Immutable is applied.  I think the 
ClassLoader used to load PropertyHandler was different from the one passed as 
"loader" to the method below.  And so the isAssignableFrom check fails.  When I 
edit (see below) to use the same class loader used for PropertyHandler, the 
check and typecast succeed.


public static PropertyHandler 
createPropertyHandler(AbstractASTTransformation xform, GroovyClassLoader 
loader, ClassNode cNode) {
List annotations = 
cNode.getAnnotations(PROPERTY_OPTIONS_TYPE);
AnnotationNode anno = annotations.isEmpty() ? null : annotations.get(0);
if (anno == null) return new 
groovy.transform.options.DefaultPropertyHandler();

ClassNode handlerClass = xform.getMemberClassValue(anno, 
"propertyHandler", 
ClassHelper.make(groovy.transform.options.DefaultPropertyHandler.class));

if (handlerClass == null) {
xform.addError("Couldn't determine propertyHandler class", anno);
return null;
}

String className = handlerClass.getName();
try {
// GRECLIPSE edit
//Object instance = loader.loadClass(className).newInstance();
Object instance = 
PropertyHandler.class.getClassLoader().loadClass(className).newInstance();
// GRECLIPSE end
if (instance == null) {
xform.addError("Can't load propertyHandler '" + className + 
"'", anno);
return null;
}
if (!PropertyHandler.class.isAssignableFrom(instance.getClass())) {
xform.addError("The propertyHandler class '" + 
handlerClass.getName() + "' on " + xform.getAnnotationName() + " is not a 
propertyHandler", anno);
return null;
}

return (PropertyHandler) instance;
} catch (Exception e) {
xform.addError("Can't load propertyHandler '" + className + "' " + 
e, anno);
return null;
}
}

Eric Milles
Lead Software Engineer
Thomson Reuters
Email: eric.mil...@thomsonreuters.com
Phone: 651-848-7040

RE: Remembering imports between script invocations

[eric.milles]

Sounds more like the Groovy Shell or Groovy Console.  Not too sure myself how 
the javax.script stuff is tied in.

From: David Ekholm [mailto:da...@jalbum.net]
Sent: Thursday, February 08, 2018 2:47 PM
To: dev@groovy.apache.org
Subject: Re: Remembering imports between script invocations

How do I do that via the javax.script API?

Even if this is possible via the javax.script API, chances are that a user 
wishes to ad-hoc add another import, but as they are forgotten between script 
invocations, it makes it hard to use Groovy to interactively create, say a 
Swing or JavaFX UI one line at a time. With BeanShell, the user can add the 
needed imports, execute that "script" and then continue to refer to the 
imported classes in the following script invocations. Making Groovy remember 
imports would make it behave in as nice fashion as the new JShell tool in Java 
9. JShell unfortunately cannot run embedded via the javax.script API :-(

Regards
/David

On 8 Feb 2018, at 21:34, 
eric.mil...@thomsonreuters.com wrote:

You can add all the imports you want to your compiler configuration and they 
will be consistently available for all scripts.

From: David Ekholm [mailto:da...@jalbum.net]
Sent: Thursday, February 08, 2018 2:12 PM
To: dev@groovy.apache.org
Subject: Remembering imports between script invocations

We're considering supporting Groovy as an additional scripting language to our 
web gallery software jAlbum 
(http://jalbum.net),
 but one aspect bugs me: It doesn't seem like import statements are remembered 
between script invocations. This makes it far harder to use Groovy to prototype 
UIs within jAlbum's scripting console than for instance BeanShell (using the 
javax.script API). We currently support the slow BeanShell scripting language 
and JavaScript. BeanShell behaves well in this regard, remembering earlier 
imported packages between script invocations. Can this be added to Groovy or is 
there some API flag we can set?

Regards
/David, jAlbum founder and client lead developer.

RE: Remembering imports between script invocations

[eric.milles]

You can add all the imports you want to your compiler configuration and they 
will be consistently available for all scripts.

From: David Ekholm [mailto:da...@jalbum.net]
Sent: Thursday, February 08, 2018 2:12 PM
To: dev@groovy.apache.org
Subject: Remembering imports between script invocations

We're considering supporting Groovy as an additional scripting language to our 
web gallery software jAlbum 
(http://jalbum.net),
 but one aspect bugs me: It doesn't seem like import statements are remembered 
between script invocations. This makes it far harder to use Groovy to prototype 
UIs within jAlbum's scripting console than for instance BeanShell (using the 
javax.script API). We currently support the slow BeanShell scripting language 
and JavaScript. BeanShell behaves well in this regard, remembering earlier 
imported packages between script invocations. Can this be added to Groovy or is 
there some API flag we can set?

Regards
/David, jAlbum founder and client lead developer.

RE: Upcoming releases

[eric.milles]

Daniel,
Could you please wait?  Each time Paul has announced 2.4 and 2.5 releases 
forthcoming, you announce 2.6 and 3.0 minutes later.  Then you end up forcing 
out 2.6 and 3.0 before 2.4 and 2.5.  This strains the intake pipelines of 
downstream projects like IDE support, etc.

-Original Message-
From: Daniel Sun [mailto:realblue...@hotmail.com] 
Sent: Tuesday, February 06, 2018 4:38 AM
To: d...@groovy.incubator.apache.org
Subject: Re: Upcoming releases

That's great.

I plan to release 2.6-alpha-3 and 3.0-alpha-2 when the 
PR(https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_apache_groovy_pull_654=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww=ssQVk8MzUlEqENextdc-oXwd4p512ZCoPo5L1rCvNTI=Zva9_D9ZBNuGZxlFEFVCYvHybCOd4-XvNIJF5MnagKw=
 ) is reviewed and merged.

Cheers,
Daniel.Sun




--
Sent from: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__groovy.329449.n5.nabble.com_Groovy-2DDev-2Df372993.html=DwICAg=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY=tPJuIuL_GkTEazjQW7vvl7mNWVGXn3yJD5LGBHYYHww=ssQVk8MzUlEqENextdc-oXwd4p512ZCoPo5L1rCvNTI=VAcvRrEcFIkiJVJ5bPj6Ow9J5kvkaXa0AHFnnux77i4=
 

Add default methods to some interfaces in Groovy 2.6+

[eric.milles]

Now that Java 8 is the minimum required runtime, could some default methods be 
added to interfaces such as org.codehaus.groovy.ast.expr.MethodCall or 
org.codehaus.groovy.ast.Variable.  For example, predicate checks like 
isStatic(), et al. could be implemented in terms of getModifiers(), would 
provide convenience to receivers of Variable instances, and would save a bunch 
of repeated overrides in implementing classes.

Can anyone think of other interfaces in core groovy that could benefit from 
default methods?

RE: About adding DGM startsWith(String...) and endsWith(String...)

[eric.milles]

Isn't the trend to use CharSequence instead of String?  If it's startsWith, 
shouldn't the signature be startsWith(String one, String two, String... more) 
to avoid zero params and conflict with 1 param built-in method?

Couldn't this be just as easily expressed using the any DGM?

['prefix1', 'prefix2', ...].any { string.startsWith(it) }

RE: Gradle build updates

[eric.milles]

"The "all" sources is still produced. But there's no all jar anymore."

Is there a way to get back to being able to produce an all jar?  I actually 
leverage the embeddable jar for embedding in another OSGi bundle.  I was 
humming along with adding Groovy 2.5 support through beta2 and now it seems I 
would have to retool my single jar handling to deal with a number of module 
jars instead.

RE: Gradle build updates

[eric.milles]

So is it still possible to produce the groovy-all.jar and 
groovy-all-sources.jar from the SDK zip?

RE: CI builds for Groovy

[eric.milles]

The JDK 8 builds are still not running because the agent is listed as 
disconnected.

RE: CI builds for Groovy

[eric.milles]

The build server mentions insufficient disk space.  Could someone have a look?

From: Milles, Eric (TR Technology & Ops)
Sent: Monday, December 11, 2017 10:40 AM
To: dev@groovy.apache.org
Subject: CI builds for Groovy

Has anyone noticed that there are 40+ pending changes waiting to build in 
TeamCity (Groovy 2.5) and no builds have run for several days?  Same goes for 
2.4, 2.6, 3.0.

Eric Milles
Lead Software Engineer
Thomson Reuters
Email: eric.mil...@thomsonreuters.com
Phone: 651-848-7040

CI builds for Groovy

[eric.milles]

Has anyone noticed that there are 40+ pending changes waiting to build in 
TeamCity (Groovy 2.5) and no builds have run for several days?  Same goes for 
2.4, 2.6, 3.0.

Eric Milles
Lead Software Engineer
Thomson Reuters
Email: eric.mil...@thomsonreuters.com
Phone: 651-848-7040

RE: About setting a stable module name with `Automatic-Module-Name` entry in MANIFEST

[eric.milles]

Shouldn't it be different for each groovy-xxx.jar?  What should it be for 
groovy-all.jar, which contains the stuff of many modules?  What about the indy 
jars?  Do they have a separate module name or a shared name with their non-indy 
counterparts?

RE: Get reference to enclosing closure

[eric.milles]

If this snippet, "this" will always refer to the enclosing class, never the 
delegate "list" or the owner (which may be the enclosing closure or "this" if 
no enclosing closure).  That is, the choice of "this" has already frozen where 
"contains" can come from.


with(list) {

  SpockRuntime.verifyMethodCondition(this, "contains", [1])
}


From: Leonard Brünings [mailto:groovy-...@bruenings-it.net]
Sent: Monday, November 20, 2017 5:52 PM
To: dev@groovy.apache.org
Subject: Re: Get reference to enclosing closure


Spock doesn't rewrite it to `this.getThisObject()`.

This is what Spock does

with(list) {

  SpockRuntime.verifyMethodCondition(this, "contains", [1])
}

The transformation from `this` to `this.getThisObject()` is done by groovy at a 
later stage.
My guess somewhere in the AST-to-Bytecode ASM code as I can see the upper 
version in the
last stage of the AST-Transforms.


with(list) {

  SpockRuntime.verifyMethodCondition(this.getThisObject(), "contains", [1])
}
Am 20.11.2017 um 22:09 schrieb 
eric.mil...@thomsonreuters.com:
When you rewrite to this form:


with(list) {

  SpockRuntime.verifyMethodCondition(this.getThisObject(), "contains", [1])
}

You've esentially frozen your choice of delegate, owner or this.  The dynamic 
resolution of "implicit this" to one of those is no longer going to happen.  I 
guess you'd need to re-implement the resolution strategy.

RE: Get reference to enclosing closure

[eric.milles]

When you rewrite to this form:


with(list) {

  SpockRuntime.verifyMethodCondition(this.getThisObject(), "contains", [1])
}

You've esentially frozen your choice of delegate, owner or this.  The dynamic 
resolution of "implicit this" to one of those is no longer going to happen.  I 
guess you'd need to re-implement the resolution strategy.

RE: Get reference to enclosing closure

[eric.milles]

I think "this" or "getThisObject()" should really be "delegate" or 
"getDelegate()".

From: Leonard Brünings [mailto:groovy-...@bruenings-it.net]
Sent: Monday, November 20, 2017 2:27 PM
To: dev@groovy.apache.org
Subject: Get reference to enclosing closure


Hi,

I'm Leonard from the Spock framework team. Guillaume suggested that I write to 
the dev-list with this problem.

Some context:

Spock has a method `with(Object, Closure)` in its Specification class that sets 
the object as the delegate of the closure and transforms,
every call inside the closure to an implicit assertion.

given:

  def person = new Person(name: "Peter", age: 28)

expect:

  with(person) {

  name == 'Peter'

  age == 28

  }

This worked fine for properties, however for single methods like `contains` it 
didn't work.

The initial problem is described here 
https://github.com/spockframework/spock/pull/606

Here is the gist:

This snippet



def list = [1, 2]

with(list) {

  contains(1)

}



transforms in AST (simplified) to

def list = [1, 2]

with(list) {

  SpockRuntime.verifyMethodCondition(this, "contains", [1])

}



then when the AST is written to bytecode it gets transformed again

def list = [1, 2]

with(list) {

  SpockRuntime.verifyMethodCondition(this.getThisObject(), "contains", [1])

}

The problem is that the `contains` is now invoked on the containing 
`Specification` instead of the `List`.

With the aforementioned PR it was changed to this

def list = [1, 2]

with(list) {

  SpockRuntime.verifyMethodCondition(this.each(groovy.lang.Closure.IDENTITY), 
"contains", [1])

}



This "fix" now broke the nesting of `with` blocks as described here: 
https://github.com/spockframework/spock/pull/782

Do you have any ideas on how to fix this elegantly?

- Cheers
Leonard

Selection of DGM from multiple options

[eric.milles]

Could someone help me understand the rules for DGMs when multiple methods 
apply?  I can't seem to find anything in the specification that addresses this 
and I need to emulate (or call into) the rules for Eclipse.  I also tried 
walking through MetaClassImpl and MetaMethodIndex, but I got lost in the cache 
loading code.

DefaultGroovyMethods defines these two methods, in this order.  At runtime, if 
I have an ArrayList, sort(Iterable,Closure) is the method that is called.  Is 
this because 1) Iterable has wider applicability than Collection, 2) the 
Collection version is deprecated, 3) the Iterable version is defined last, or 
4) something else?

@Deprecated
public static  List sort(Collection self, 
@ClosureParams(value=FromString.class, options={"T","T,T"}) Closure closure) {
...
}

public static  List sort(  Iterable self, 
@ClosureParams(value=FromString.class, options={"T","T,T"}) Closure closure) {
...
}

Eric Milles
Lead Software Engineer
Thomson Reuters
Email: eric.mil...@thomsonreuters.com
Phone: 651-848-7040

RE: upcoming releases

[eric.milles]

Are we really ready to have 3 unfinished versions making their way through 
alpha/beta?  I haven't even had time to look into 2.6 yet.

RE: `this` in static context

[eric.milles]

For sure , "this" and "super" are supported within a closure defined in a 
static context.  Are you saying they also work directly in a static method?  
Given "class A { static main(args} { this } }", this should be of type 
"Class" if it is indeed supported.  It follows that it would work, since you 
can call directly methods on Class from that scope, like getCanonicalName().

New syntax explosion

[eric.milles]

Before Groovy 2.6 and 3.0 are released, will there be a review of the syntax 
additions for inclusion in the final release?  I get "!in" and "!instanceof".  
However, I'm am getting the feeling of "Kitchen Sink" or "just because we can" 
on recent additions to the parser.  I'm not seeing any of the new syntax adding 
something I can't get already with reasonably succinct code:

`foo?['bar']` is just `foo?.getAt('bar')`

`a === b` is just `a.is(b)`

`a ?= b` is just `if (!a) a = b`

`a??.b.c.` is just `a?.b?.c`

'def a = if (x) b else c` is just `def a = x ? b : c`

`def a = switch (x) { case 'b': b; break; case 'c': c; break; }` (or whatever 
has been proposed) is just `def a = { switch(x) { ... } )()`

These last two really bother me because statements and expressions have a 
distinct meaning in the language and now the meaning is blurred quite 
completely.  Why is all of this new syntax necessary?  Isn't it enough to have 
support for Java array init and lambdas now?


All these new syntax options are making it difficult to entice fellow Java 
programmers around the office into using Groovy because it is Java plus a *few* 
very convenient additons.  I almost want to be able to turn off some of these 
additions so the compiler errors on them.

Eric Milles
Lead Software Engineer
Thomson Reuters
Email: eric.mil...@thomsonreuters.com
Phone: 651-848-7040