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 10:02, 12 February 2011 by Andreas.kaluza.net (Talk | contribs) (Package Structure: continue)

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 support the software engineer while coding. There are a lot of scenarios, where a programmer has no clue to instantiate a variable in a specific context ("How do I get an instance of IWorkbenchHelpSystem?"). This plug-in searches through the programming context for all members, which meet the search criteria. The results, namely call chains, are visualized as proposals within the editor. Finally the coder can pick the right one.

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 package and 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 proposal box.

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 ChainCompletion is triggered at this point 'someString.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

The first subsection #Package Structure describes the packages and their responsibilities. Next the subsection #Class Overview contains all classes, which are briefly illustrated.

Package Structure

Package Description Content
[*].chain Desc TODO Classes TODO
[*].chain.algorithm Desc TODO Classes TODO
[*].chain.algorithm.internal Desc TODO Classes TODO
[*].chain.proposals Desc TODO Classes TODO
[*].chain.util Desc TODO Classes TODO

Class Overview

Class Description
ChainedJavaCompletionProposalComputer Desc TODO
Constants Desc TODO
ChainedJavaProposal Desc TODO
ChainingAlgorithm Desc TODO
ChainedProposalAnchor Desc TODO
ChainingAlgorithmWorker Desc TODO
FieldChainWalaElement Desc TODO
FieldsAndMethodsCompletionContext Desc TODO
MethodChainWalaElement Desc TODO
TemplateProposalEngine Desc TODO
LookupUtilJdt Desc TODO
LookupUtilWala Desc TODO

Back to the top