Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Recommenders/Attic/ChainCompletion

< Recommenders
Revision as of 09:33, 11 February 2011 by Andreas.kaluza.net (Talk | contribs) (Algorithm: name convention: plugin is called ChainCompletion and not callchain)

ChainCompletion Intro

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

ChainCompletion Architecture

The first section #Workflow introduces the main idea of this plug-in and describes briefly how it is implemented. The next Section #Structural Overview goes into the class design and explicates it.

Workflow

The section is separated into two subsections. First the idea of the #Algorithm is explained. This algorithm is responisble to compute all possible call chains. After the chains were computed, the #Proposal Generation starts to build the proposals, which were displayed on the editor.

Algorithm

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

1. Scenario
IWorkbenchHelpSystem c = PlatformUI.//trigger ChainCompletion here
2. Scenario
class TestClass {
 
   IWorkbenchHelpSystem findMember = PlatformUI.getWorkbench().getHelpSystem();
 
   public void someMethod () {
      IWorkbenchHelpSystem findVariable = PlatformUI.getWorkbench().getHelpSystem();
 
      IWorkbenchHelpSystem c = //trigger ChainCompletion 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 expected 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 ChainCompletion is triggered as in scenario 2 all variables, fields and method are considered independently of their visibility. In scenario 1 only the accessible public fields and methods are contemplable.

With this information (expected type, accessible members) the main 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 third step, are stored in lists. Actually only the type (return type) and member name are considered.

For each list a thread worker process starts. First the last element of the list is retrieved (in the beginning there is only one element in the list). The worker checks the objective for this type:

  • If the type matches the expected type this list is stored for the #Proposal Generation.
  • In the other case a new calling context is set to the type which was retrieved. Like in the beginning all accessible members are determined. For each member the list has to be cloned and the members are stored at the end of each list. The computation algorithm starts from the beginning for each list.

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 ChainCompletion does not work on primitives. The solution is to box this primitives to their corresponding type
  • The ChainCompletion 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 be generated.
  • The ChainCompletion works only on public members. In an inheritance hierarchy whether protected nor package private members will be found.
  • //TODO

Proposal Generation

//TODO

Structural Overview

//TODO

Back to the top