GroovyInterceptable should cause properties to fall back to getXXX/setXXX

get/setProperty is used by default already. As an example:

class Foo {
  def x = 1
  def getProperty(String name) {2}
}
def foo = new Foo()
assert foo.x == 2

so nothing to do?

Ah, okay – I need to clarify.

This code:

class Recorder implements GroovyInterceptable {

def toInvoke = []

def invokeMethod(String name, args) {
switch(name) {
case "record":
args[0].delegate = this
args[0](this)
break
case "playback":
toInvoke.each

break
default: toInvoke << [name, args]
}
}

}

def r = new Recorder()
r.record {
it.foo
it.bar = 5
}

Throws this exception:

Caught: groovy.lang.MissingPropertyException: No such property: foo for class: Recorder
at recorder_demo$_run_closure1.doCall(recorder_demo.groovy:25)
at Recorder.invokeMethod(recorder_demo.groovy:10)
at recorder_demo.run(recorder_demo.groovy:24)

It can be fixed by adding this code to the Recorder:

def getProperty(String propertyName)

void setProperty(String propertyName, newValue)

It'd be nice if that code didn't have to be added: if properties would eventually delegate back to invokeMethod, too.

This request came out of code exploration here:
http://enfranchisedmind.com/blog/posts/groovy-recorder/

so the problem is not that "println foo.bar" goes through getProperty(String) it is that the call to getProperty(String) does not go through invokeMethod, even though we have GroovyInterceptable. Well... currently you cannot even dynamically replace get/setProperty or invokeMethod combined with GroovyInterceptable. That is because a direct method call is done for them atm. Your proposed logic requires a dynamic method call to those methods. Which of course also means that invokeMethod will always have to handle get/setProperty too. So the maximum is to set this for 2.0

My proposal would be for the default implementation of getProperty to end with something like:

if(this instanceof GroovyInterceptable) {
  invokeMethod("getProperty", name)
}

And the default implementation of setProperty to end with something like:

if(this instanceof GroovyInterceptable) {
  invokeMethod("setProperty", [name, value] as Object[])
}

(or whatever)

So then, instead of throwing a MissingProperty exception, we're giving invokeMethod a chance to handle it.

I assumed that this wouldn't be targeted for anything less than 2.0 (hence the "Improvement", not "Bug" categorization).

wait... you want the method to be called to call itself? I mean interception means to get to a point where the method call has been initiated, but the actual method is not yet called. For getProperty(String) that for example means to react to that method call before the method is actually called. If the method just calls itself, you end up with a endless loop or stack overflow. You try to limit this by checking for GroovyInterceptable, but what should invokeMethod then call? If it tries to actually call getProperty you end up in invokeMethod again! I think this won't do.

btw, using a custom meta class would be much better for this kind of stuff.

get/setProperty are handled by invokeMethod is they are called as methods. So "not at all" seems to exaggerate a bit. I only wanted to hint, that this way to implement the methods doesn't help very much.

How a MetaClass is better? Well, not so much for Interceptable, but normally you don't want to change the static class delcaration to record. So IMHO this goes more into Mocking and Stubbing. And here Groovy has MockFor and StubFor and those use ProxyMetaClass to accomplish their task. Using ProxyMetaClass is much less complicated than a full blown meta class of course.