[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
| RE: [cdt-dev] Refactoring binding question | 
Hi Tom,
when the index is used for a refactoring, it is always used 
in a read-only manner. It speeds up the creation of ASTs,
because you can then skip header files. If you do not 
skip headers, refactorings will suffer from performance problems, depeding on 
how many files they need to look at and how many headers are included by 
those.
 
From the client perspective it should not make a difference 
whether a name resolves to a binding from the AST or the index. The fact that 
the method you mention is not implemented, can easily be fixed. You can also 
work around it by using IBinding.getScope() or 
IBinding.getOwner().
 
Markus.
  
  
  Found it -- if your refactoring runner locks the index before 
  running (like ExtractConstantRefactoringRunner does), then bindings use the 
  Composite versions.  Running my refactoring without locking the index 
  (like ExtractFunctionRefactoringRunner does) fixes my immediate 
  issue.
On a more general note, when should CRefactoring.lockIndex() be 
  used?  I locked it because my refactoring defines a new variable and so 
  (I assume) modifies the index.  So does ExtractFunctionRefactoring, 
  however, without any apparent problems.
Tom
  
On Sun, Sep 28, 2008 at 9:24 AM, Sergey Prigogin 
<eclipse.sprigogin@xxxxxxxxx> 
  wrote:
  
    CompositeCPPFunction is an index binding (see the comment at 
    the top of CompositeIndexBinding). CPPFunction is a binding from AST. I 
    don't know why isGloballyQualified is not implemented for most index 
    bindings.
-sergey
    
    
    
      
      
      
      My refactoring needs to lookup a function declaration binding 
      from a call to it, so it uses a NodeContainer.findAllNames() method to 
      resolve the function call's name.  The name's binding is a 
      CompositeCPPFunction, but when the ExtractFunctionRefactoring runs the 
      same code, it gets a CPPFunction for the same selection in the same 
      file.  I can't figure out what's different between the two 
      refactorings (both lookups are done in checkInitialConditions(), so there 
      hasn't been much setup yet).  What is the difference between a 
      CompositeCPPFunction and a CPPFunction?  The difference matters 
      because the PDOM support for CompositeCPPBinding.isGloballyQualified() 
      isn't implemented.
Any help would be 
      appreciated.
Tom
  _______________________________________________
cdt-dev 
      mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
 
_______________________________________________
cdt-dev 
    mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev