Allow DSLD to define the 'delegate' type for a particular closure

If you are trying to achieve something like grail's resources.groovy where you have single file that assigns a closure to a binding variable, the easiest way of "prescribing required methods/properties within a closure" is to simply use enclosingCallName("method"). You can use this in conjunction with fileName("my-file.groovy") to limit the scope of the pointcut.

One thing I find annoying is that, from what I understand, one cannot limit the call to the top-level scope of closure body. What this means is that if you have a structure like:

reports = { 
   report { 
      params { 
          param(...) 
      } 
   } 
} 

You cannot limit the applicability of the param call to the params body unless you do something like the following in your DSLD file:

 
// Base pointcuts 
def reportsFile = fileName("report-definitions.groovy") 
def reportsCall = enclosingClosure() 
def reportCall  = enclosingCallName("report") 
def paramsCall  = enclosingCallName("params") 

// Composite pointcuts 
def globalScope  = reportsFile & ~reportsCall & ~reportCall & ~paramsCall 
def reportsScope = reportsFile & reportsCall & ~reportCall & ~paramsCall 
def reportScope  = reportsFile & reportCall & ~paramsCall 
def paramsScope  = reportsFile & paramsCall 

As you can see, you have to exclude all other scopes to achieve the desired effect. It would be nice if there were a pointcut like enclosingScopeCallName that provided this capability since it is often what is required for builder-based DSLs.

Some initial success prototyping a solution for this. I should be able have a real implementation available soon.

Turns out my initial prototyping uncovered the problem described in GRECLIPSE-1318, which is now fixed. I am thinking of a bit of a different solution than what you are suggesting.

contribute(enclosingClosure() & enclosingCallName("report")) {
  setDelegateClass 'com.foo.MyClass'
}
contribute(enclosingCallName("params")) {
  setDelegateClass 'com.foo.MyOtherClass'
}

This will set the type of the closure's delegate field to com.foo.MyClass or whatever is specified.

Although you are asking for a more precise way to match inside of a closure, but not inner closures, this solution gives you a way to precisely specify the value of delegate inside of a given closure. This should be sufficient.

If you need to handle inner closures, then the simply take advantage of the fact that in dslds, contribution blocks are executed in lexical order. And so, if 2 pointcuts match and each one does a setDelegateType, the second one will always trump the first.

I am not committing anything yet, but this is my planned solution. Any comments?

Although useful, I don't know how practical this would be for builder-based dsls. For builder dsls, the delegate is often the same class in each scope, but for the purpose of the dsl calls must be restricted based on scope. With your proposal, one would have to create artificial classes to satisfy the dsl scope restriction requirement.

What is required is the DSLD equivalent of AspectJ's withincode(MethodPattern) pointcut. I would think this would be easy to implement in AST terms, but what do I know

I think what you are asking for is a variant of enclosingCallName that only looks at the closest call, something like closestEnclosingCallName (not sure if I like the name, though).

So:

contribute(closestEnclosingCallName("report")) {
  ...
}

report {
  // 1
  params {
    // 2
  }
}

So, this would match at 1, but not 2. However, this might be a problem because of this:

report {
  [list, of, reports].each {
     // do something reporty here
  }
}

I would expect that the contributions would have to work inside of the each closure. So, it's hard for me to see how you can specify the builder without being extremely specific.

OK. I committed some initial work on setDelegateType. This should help Kris's initial problem. This is still a bit untested and I want to know if it works for you, Kris, so we can work on this next week.

Bob, I'm beginning to think that your requirements are different enough that we should discuss this on a different issue. If I get a chance tonight, I'll raise a new issue.

I think you're right. My requirement is a bit different.

Your example does point out some edge cases exist. However, I don't think there would be a problem with the each call since the delegate would most certainly be the list and not the builder. Thus, I wouldn't expect the pointcut to match. Inside builders, it is more common to see a for/in loop so that the delegate is preserved to participate in pretended method / property resolution.

It is hard for me to say off the bat if this will work. I think it will work for me, but I'll have to try it out and play with it a bit. I'll post back when I had a chance to do that.

Based on discussions with Kris, this appears to work for his case. I committed the change with regression tests.

I already updated the meta DSLD, so setDelegateType will not be underlined.

Still need to update docs on the wiki.

I created GRECLIPSE-1323. Bob, is something like this sufficient to address the problem you are having?