Bug 53586 - Need interface for "invocation" ast nodes
Summary: Need interface for "invocation" ast nodes
Status: RESOLVED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 3.0 M8   Edit
Assignee: Jim des Rivieres CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-03 06:10 EST by Markus Keller CLA
Modified: 2004-06-09 12:15 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Keller CLA 2004-03-03 06:10:36 EST
There are currently 5 nodes in the public java ast which stand for different
forms of "invocations": ClassInstanceCreation, ConstructorInvocation,
MethodInvocation, SuperConstructorInvocation, and SuperMethodInvocation.

What they have in common is a query 'List arguments()', which returns a list of
argument Expressions. Our refactoring code sometimes doesn't care about the
exact invocation form. In that case, I'd like better static typing with a
possibilty to declare a variable of e.g. type IInvocation, where IInvocation is
a new interface with a query 'List arguments()'. Currently, I have to use
ASTNode and downcast every time.

The interface could also declare resolveMethodBinding()
(the constructors would then need a delegate to resolveConstructorBinding()).
Comment 1 Jim des Rivieres CLA 2004-03-04 10:49:05 EST
Could you not just pass around the List<Expression> arguments() itself?
Comment 2 Markus Keller CLA 2004-03-09 06:06:24 EST
Yes, I can pass around the arguments List and the MethodBinding along with the
ASTNode, but I thought client code would become cleaner when it could just use a
single IInvocationNode instead.

However, I see that such "view" interfaces could be asked for many subsets of
ASTNodes. They would have to be added everywhere or nowhere, but not just for
this single case. As a client, I would like to have them, but if you think it
would hamper future ast api evolution, I can also live without.
Comment 3 Jim des Rivieres CLA 2004-03-09 07:04:40 EST
The main issue here is whether the benefits to clients of adding the interface 
outweigh the costs (extra interfaces in the API make it harder for clients to 
see what's important). I would prefer to hold off adding extra API types 
unless there is a bigger payoff.

Please reopen PR if you feel this would be a big win.
Comment 4 Adam Kiezun CLA 2004-06-09 12:15:20 EDT
i too think that this is important.
what i have to pass around now is ASTNode which is just bad.
this is a more general issue with the AST API.
see various jdt ui's workarounds in ASTNodes: 
isLiteral, isLabel, isStatic (no interface that had 'getModifiers')

for the invocations problem see that Invocations class:
it has methods like isInvocation, getArguments, resolveMinding

other clients do the same, probably