| Relationship (if any) between CompilationUnit and ICompilationUnit ? [message #249850] |
Tue, 27 November 2007 12:10  |
Eclipse User |
|
|
|
Originally posted by: myawn.ebay.com
I've always been confused by the relationship between CompilationUnit
and ICompilationUnit. Most places in Eclipse where there is naming of
this sort, you would expect CompilationUnit to be a class that could be
easily assigned to a declared ICompilationUnit (an interface type).
In my AST manipulation code, I've always had the following bit of code
that was copied (more or less) from an example I found:
protected AST m_ast;
private ASTParser m_parser;
protected ICompilationUnit m_input;
protected CompilationUnit m_unit;
public AST parseSource(ICompilationUnit input, boolean resolveBindings) {
m_input = input; // remember for reparse
m_parser = ASTParser.newParser(AST.JLS3);
m_parser.setKind(ASTParser.K_COMPILATION_UNIT);
m_parser.setSource(input);
if (resolveBindings)
m_parser.setResolveBindings(true);
m_unit = (CompilationUnit) m_parser.createAST(null);
m_unit.recordModifications();
m_imports = m_unit.imports();
m_ast = m_unit.getAST();
return m_ast;
}
(Local coding standards require the m_ prefix on member variables; it's
repugnant, but you've got to choose your battles).
I've never been clear about the relationship between the
ICompilationUnit that is passed in, and the CompilationUnit that results
from the .createAST call. If anyone can point me to a clear
explanation of this, it might help me out. CompilationUnit doesn't
implement ICompilationUnit, but rather extends ASTNode.
My immediate problem is this: I've got an ASTVisitor that is updating
method names, but the changes aren't being persisted. I've got several
other visitors that do similar operations, and they all seem to work
fine, so I'm really stuck as to why this one isn't working. In
stepping through things in debug, I find that the CompilationUnit is
being updated, but the ICompilationUnit is not. When the visitor
completes, it is the ICompilationUnit that I'm passing into my
writeChanges method that applies edits to the underlying document.
(Again, this pattern seems to work several other places, and I can't
just pass m_unit, above, into writeChanges instead of m_input, since the
types aren't assignable).
Any help in understanding CompilationUnit vs. ICompilationUnit would
probably help me gain a better understanding here. Any other
suggestions as to why my visitor's changes aren't getting persisted
would be even more helpful :-).
Thanks,
Mike
|
|
|
| Re: Relationship (if any) between CompilationUnit and ICompilationUnit ? [message #249856 is a reply to message #249850] |
Tue, 27 November 2007 14:20  |
| Eclipse User |
|
|
|
Originally posted by: wharley.bea.com
"Mike Yawn" <myawn@ebay.com> wrote in message
news:fihj19$3s7$1@build.eclipse.org...
> I've always been confused by the relationship between CompilationUnit and
> ICompilationUnit.
My understanding is that it is an accident of history, relating to the fact
that Eclipse itself is the integration of several older projects. By the
time the projects came together there were API names that didn't make sense
together but would be awkward to change.
In addition to ASTNode, there are two distinct and unrelated
ICompilationUnit interfaces:
org.eclipse.jdt.internal.compiler.env.ICompilationUnit, in the compiler
org.eclipse.jdt.core.ICompilationUnit, in the Java Model
Then there are a bunch of unrelated CompilationUnits:
org.eclipse.jdt.core.dom.CompilationUnit, in the DOM AST, extends ASTNode;
org.eclipse.jdt.internal.core.CompilationUnit, in the Model, implements
org.eclipse.jdt.core.ICompilationUnit;
org.eclipse.jdt.internal.core.jdom.CompilationUnit, in the JDOM, is a stub
implementation of org.eclipse.jdt.internal.compiler.env.ICompilationUnit;
org.eclipse.jdt.internal.compiler.batch.CompilationUnit, in the compiler,
implements org.eclipse.jdt.internal.compiler.env.ICompilationUnit.
Note that many of these types are "internal".
|
|
|
Powered by
FUDForum. Page generated in 0.51164 seconds
Home