Best way to do AOP-like stunts?

[Robert Fischer]

I'd like to wrap all calls into a particular library that contain a particular type of argument, and
then do some adjustment to that argument before it continues processing.  I specifically do *not*
want to override/define invokeMethod, because I suspect someone else might be hijacking that for
their own nefarious purposes, and I'm concerned I'll trounce their work (or vice versa).  What's the
best way to go about this?  If I iterate over the MetaMethods, I'm not entirely sure how to redefine
the calls so that my new implementation can call the old implementation with the appropriately
mangled argument.  Is there an idiom I should be using for this kind of behavior?

What I really want is something like Java 7's method handles...

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

[Ted Naleid-2]

It's hard to know without more details, but this approach might work for you:

http://naleid.com/blog/2009/06/01/groovy-metaclass-overriding-a-method-whilst-using-the-old-implementation/

It doesn't whack invokeMethod and simply uses the reference to the old method (whatever that may be).

-Ted

On Mon, Jun 22, 2009 at 12:15 PM, Robert Fischer <robert.fischer@...> wrote:

I'd like to wrap all calls into a particular library that contain a particular type of argument, and
then do some adjustment to that argument before it continues processing.  I specifically do *not*
want to override/define invokeMethod, because I suspect someone else might be hijacking that for
their own nefarious purposes, and I'm concerned I'll trounce their work (or vice versa).  What's the
best way to go about this?  If I iterate over the MetaMethods, I'm not entirely sure how to redefine
the calls so that my new implementation can call the old implementation with the appropriately
mangled argument.  Is there an idiom I should be using for this kind of behavior?

What I really want is something like Java 7's method handles...

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

[Robert Fischer]

Perfection itself.

~~ Robert.

Ted Naleid wrote:

> It's hard to know without more details, but this approach might work for
> you:
>
> http://naleid.com/blog/2009/06/01/groovy-metaclass-overriding-a-method-whilst-using-the-old-implementation/
>
> It doesn't whack invokeMethod and simply uses the reference to the old
> method (whatever that may be).
>
> -Ted
>
> On Mon, Jun 22, 2009 at 12:15 PM, Robert Fischer
> <robert.fischer@...
> <mailto:robert.fischer@...>> wrote:
>
>     I'd like to wrap all calls into a particular library that contain a
>     particular type of argument, and
>     then do some adjustment to that argument before it continues
>     processing.  I specifically do *not*
>     want to override/define invokeMethod, because I suspect someone else
>     might be hijacking that for
>     their own nefarious purposes, and I'm concerned I'll trounce their
>     work (or vice versa).  What's the
>     best way to go about this?  If I iterate over the MetaMethods, I'm
>     not entirely sure how to redefine
>     the calls so that my new implementation can call the old
>     implementation with the appropriately
>     mangled argument.  Is there an idiom I should be using for this kind
>     of behavior?
>
>     What I really want is something like Java 7's method handles...
>
>     ~~ Robert Fischer, Smokejumper IT Consulting.
>     Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>     Check out my book, "Grails Persistence with GORM and GSQL"!
>     http://www.smokejumperit.com/redirect.html
>
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

[Robert Fischer]

Spoke too soon -- you end up hitting the same catch I was hitting before, just in a different way
than I was.

Here's the catch: your code has lots of explicit definitions.

Your code:

def oldPlus = Integer.metaClass.getMetaMethod("plus", [Integer] as Class[])

Integer.metaClass.plus = { Integer n ->
    return oldPlus.invoke( Math.abs(delegate), Math.abs(n) )
}

My code:

def oldMethods = Foo.metaClass.methods.find { ... }

oldMethods.each { MetaMethod oldMeth ->
  Foo.metaClass.???? = { ?????

That's where it falls down -- how do I specify the new method declaration?

~~ Robert.




Robert Fischer wrote:

> Perfection itself.
>
> ~~ Robert.
>
> Ted Naleid wrote:
>> It's hard to know without more details, but this approach might work for
>> you:
>>
>> http://naleid.com/blog/2009/06/01/groovy-metaclass-overriding-a-method-whilst-using-the-old-implementation/
>>
>> It doesn't whack invokeMethod and simply uses the reference to the old
>> method (whatever that may be).
>>
>> -Ted
>>
>> On Mon, Jun 22, 2009 at 12:15 PM, Robert Fischer
>> <robert.fischer@...
>> <mailto:robert.fischer@...>> wrote:
>>
>>     I'd like to wrap all calls into a particular library that contain a
>>     particular type of argument, and
>>     then do some adjustment to that argument before it continues
>>     processing.  I specifically do *not*
>>     want to override/define invokeMethod, because I suspect someone else
>>     might be hijacking that for
>>     their own nefarious purposes, and I'm concerned I'll trounce their
>>     work (or vice versa).  What's the
>>     best way to go about this?  If I iterate over the MetaMethods, I'm
>>     not entirely sure how to redefine
>>     the calls so that my new implementation can call the old
>>     implementation with the appropriately
>>     mangled argument.  Is there an idiom I should be using for this kind
>>     of behavior?
>>
>>     What I really want is something like Java 7's method handles...
>>
>>     ~~ Robert Fischer, Smokejumper IT Consulting.
>>     Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>>
>>     Check out my book, "Grails Persistence with GORM and GSQL"!
>>     http://www.smokejumperit.com/redirect.html
>>
>>
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

[kartikshah]

It is possible for no parameter method this way... 

class Example

{

    def show(){ println 'Hello World'}

    static void main(String[] arguments){

     def pointcutMethods = Example.metaClass.methods.findAll{it.name.startsWith 'show'}

     def advise = { MetaMethod oldMethod, delegate1, Object... args ->

    println 'Before Invocation ' + args

oldMethod.doMethodInvoke(delegate1, args)

println 'After Invocation'

    }

    

    pointcutMethods.each{ MetaMethod oldMethod -> 

    def methodName = oldMethod.name

Example.metaClass."$methodName" = { ->

advise(oldMethod, delegate, null)

    }

     }

    

    def ex = new Example();

    ex.show()

    }

But haven't had luck with to do this dynamically for methods having parameter. It needs explicit definition of Parameter list. 

- Kartik

 

On Jun 22, 2009, at 1:34 PM, Robert Fischer wrote:

Spoke too soon -- you end up hitting the same catch I was hitting before, just in a different way
than I was.

Here's the catch: your code has lots of explicit definitions.

Your code:

def oldPlus = Integer.metaClass.getMetaMethod("plus", [Integer] as Class[])

Integer.metaClass.plus = { Integer n ->
   return oldPlus.invoke( Math.abs(delegate), Math.abs(n) )
}

My code:

def oldMethods = Foo.metaClass.methods.find { ... }

oldMethods.each { MetaMethod oldMeth ->
 Foo.metaClass.???? = { ?????

That's where it falls down -- how do I specify the new method declaration?

~~ Robert.




Robert Fischer wrote:

Perfection itself.

~~ Robert.

Ted Naleid wrote:

It's hard to know without more details, but this approach might work for

you:

http://naleid.com/blog/2009/06/01/groovy-metaclass-overriding-a-method-whilst-using-the-old-implementation/

It doesn't whack invokeMethod and simply uses the reference to the old

method (whatever that may be).

-Ted

On Mon, Jun 22, 2009 at 12:15 PM, Robert Fischer

<robert.fischer@...

<robert.fischer@...>> wrote:

   I'd like to wrap all calls into a particular library that contain a

   particular type of argument, and

   then do some adjustment to that argument before it continues

   processing.  I specifically do *not*

   want to override/define invokeMethod, because I suspect someone else

   might be hijacking that for

   their own nefarious purposes, and I'm concerned I'll trounce their

   work (or vice versa).  What's the

   best way to go about this?  If I iterate over the MetaMethods, I'm

   not entirely sure how to redefine

   the calls so that my new implementation can call the old

   implementation with the appropriately

   mangled argument.  Is there an idiom I should be using for this kind

   of behavior?

   What I really want is something like Java 7's method handles...

   ~~ Robert Fischer, Smokejumper IT Consulting.

   Enfranchised Mind Blog http://EnfranchisedMind.com/blog

   Check out my book, "Grails Persistence with GORM and GSQL"!

   http://www.smokejumperit.com/redirect.html

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html