Difference between revisions of "Recommenders/Attic/ChainCompletion"

Revision as of 08:28, 9 February 2011

CallCompletion Intro

The CallCompletion plug-in is based on the paper 'XSnippet: Mining For Sample Code' by Naiyana Tansalarak and Kajal Claypool. The purpose is to ... //TODO

CallCompletion Architecture

IJavaCompletionProposalComputer

The class which implement this interface starts the #Algorithm, which computes the possible solution chains. After the solution chains were computed, the #Proposal Generation starts to build the proposals.

Algorithm

To understand the algorithm there are two scenarios which are important:

1. Scenario

IWorkbenchHelpSystem c = PlatformUI.//trigger plug-in here

2. Scenario

class TestClass {
 
   IWorkbenchHelpSystem findMember = PlatformUI.getWorkbench().getHelpSystem();
 
   public void someMethod () {
      IWorkbenchHelpSystem findVariable = PlatformUI.getWorkbench().getHelpSystem();
 
      IWorkbenchHelpSystem c = //trigger plug-in here
    }
 
   private IWorkbenchHelpSystem findMethod() {
      return PlatformUI.getWorkbench().getHelpSystem();
   }
}

The first step is to compute the calling context. The calling context for the first scenario is 'org.eclipse.ui.PlattformUI', because of its static access. The calling context for the second scenario is 'TestClass', because it is an access from the 'this' context.

The second step is to find out the excepted type. The expected type for both scenarios is 'IWorkbenchHelpSystem'.

The third step is to determine, which member from the calling context should be taken into account for the computation. If the callchain is triggered as in scenario 2 all variables, fields and method independent their visibility are considered. In scenario 1 only the accessible public fields and methods are contemplable.

With this information (expected type, accessible members) the actual algorithm can start. The objective of this algorithm is to to find for each type a call chain which matches the expected type. In scenario 1 the call chain is '[PlatformUI.]getWorkbench().getHelpSystem()' ('PlatformUI' does not belong to the call chain, because it is the calling context). For that all variables, fields and methods, which were found in the thrid step, are stored in linked lists. Actually only the type (return type) and member name is considered.

For each linked list a thread worker process starts. First the last element of the list is retrieved (in the beginnin there is only one element in the list). The worker checks the objective for this type. If the type matches the expected type the linked list is stored for the #Proposal Generation. In the other case the calling context changes for this linked list to the type which was retrieved. Like in the beginning all accessible members are determined. For each member the linked list has to be cloned and the members are stored at the end of each list. For the new lists the computation starts from the beginning.

At the end of computation scenario 1 has one linked list (chain depth 3). In this list contains following elements: 'getWorkbench()' and 'getHelpSystem()' with their return types. Scenario 2 will have three linked list with only one element each:

1. findMember
2. findMethod
3. findVariable

These lists are give to the #Proposal Generation.

Specifics:

• The objective can be reached, if the type can be casted to the expected type
• Redundant chain elements are deleted. E.g. String s = toString().toString().toString()...
• The determination of all members takes a lot of computation time. So all determined members are temporary stored.
• //TODO

TODOs:

• The call chain does not work on primitives. The solution is to box this primitives to their corresponding type
• The call chain cannot resolve parameters. E.g. method 'contains(CharSequence)' of the string class. If the plug-in is triggered at this 'point string.contains(*' no proposal would generated
• //TODO

Proposal Generation

//TODO