Hi again, in the previous msg there is an error I had not noticed. The line that reads
"$_=Similar.method("\"+m.getMethodName()\"" +",$args);" +
was supposed to be:
"$_=Similar.method("+m.getMethodName()+",$args);" +
(m is a MethodCall)
However, neither the first or the second work (though the first is clearly wrong), and
this shows yet another problem I'm getting, appart from the "nested method calls"
problem I originally wanted to draw attention to.
This other problem I have is that apparently I can't pass the name of the originally
called method, as an argument to the method call replacement. The Javassist compiler
complains about this saying:
javassist.CannotCompileException: [source error] no such field: toBytes
(here toBytes is the name of the method called)
If Javassist doesn't support this, then my problem is even bigger than the original
problem I posted.
I'd appreciate if Chiba or another developer (although it seems Chiba is the only
developer working in Javassist) could help me by commenting on this.
I've previously worked with BCEL, and I've done similar things to what I want to do
here, although with a lot more work. Coming across Javassist made me think I could
manipulate method calls without effort (with BCEL one needs to parse the method calls
before being able to manipulate them as such!).
It seems Javassist is intended to give developers a source-level abstraction. However,
passing a String with tokens of special meaning ($_, $0, $$, etc.), to a replace
method is way too obscure and doesn't provide the flexibility I would expect from a
source-level abstraction.
If Javassist parses a class file into some kind of AST structure, then it would be
much more intuitive for a developer to work with expression and statement objects that
are aware of their context, therefore reflecting the nested and recursive nature of
the grammar.
For instance, it seems more intuitive (and helpful) if a MethodCall object had the
following methods:
- isParameter() : returns true if this method call is nested inside another one
- getEnclosingMethodCall(): if isParameter() is true, returns the enclosing MethodCall
object.
- getParameters(): returns an array of the parameters, some of which may be
MethodCall's.
-setTargetClass: changes the target class of the method
-setMethodName: changes the name of the method being called
-setParameters, and so on...
Then, having those methods available, replace() could be a void method appended after
doing the transformations needed to the parameters, target class, method name, etc.
Finally, a Method object, could have a getMethodCalls(), and then one would be able to
probe each one, to see their nested structure, and lay out (and therefore manipulate)
the list of MethodCall's in the exact same way they are presented in a source text
editor. This can be extended to all other expressions and constructs such as loops
(also reflecting their nested structure).
A getAllExprs() call to a Method object could return a sequential list of all
expressions, and statements in the method body, each one being able to reflect their
precise context, that is, their sequential and nested relationship to the others.
I am aware that implementing such behavior would probably require a complete change of
direction. But I'm not just being demanding or critical. I'd like to help implementing
such changes/additions to the library. Maybe I should be posting this in the
developer forum as well :) . I think that unless expressions(field access, method
calls) and statements (loops, conditionals, etc.) can be manipulated in such ways, a
real source-level abstraction will be a far goal.
Thanks again,
Martin
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3837708#3837708
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3837708
-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
>From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
