Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Language IDEs » Java Development Tools (JDT) » Call Chain Completion - Limiting Search Space
Call Chain Completion - Limiting Search Space [message #761927] Wed, 07 December 2011 09:50 Go to next message
Marcel Bruch is currently offline Marcel BruchFriend
Messages: 289
Registered: July 2009
Senior Member

Hi,

this is the beginning of a series of questions/design decisions regarding a call chain completion engine for/based-on JDT (see http://code-recommenders.blogspot.com/2010/12/how-do-i-get-instance-of.html if you need more information on call chain completion). The intent of these questions is to discuss implementation decisions before the code gets written and to learn what people appreciate most. Thus, your feedback (as Eclipse User) is very appreciated.

This post is about limiting the search space as soon as a known type has been observed. See the example below:

index.php/fa/6361/0/

When triggering code completion on "PlatformUI.<^Space>", we get 7 proposals with a length up to 5 (search has been limited to maxlength=5)). As you can see, there is a circle in the call-graph for IWorkbench:

getWorkbench() -> getActiveWorkbenchWindow() -> getWorkbench()
getWorkbench() -> getWorkbenchWindows()[index] -> getWorkbench()
getWorkbench() -> showPerspective() -> getActiveWorkbenchWindow() -> getWorkbench()

and so on. There are other examples with an even worse dependency graphs.

Question: How should the engine deal with these kinds of circles?

Option 1: Stop as soon as the same type has been part of the chain?
This would cut off many paths, potentially also interesting ones. (Need an example?)

Option 2: Put in as many paths as possible to find until completion timeout occurs.
This is not perfectly heuristic and leads to many results. People might get flooded with proposals. In this case, call-chain completion should work as a quick fix rather than a code completion (maybe it should do so in general).

Option 3: Limit the number of proposal to the, say, 7 shortest proposals.
People don't get flooded but probably don't get the proposals they want.


As a side-note: We have in mind an approach that collects the information which proposals have been used actually used in similar situations. Given this info, we can cut down the number of proposals furthermore.

Deepak (and anyone else interested in this), whats your opinion on that? Option 1, 2, or 3? Or something different?

Cheers,
Marcel

[Updated on: Wed, 07 December 2011 09:56]

Report message to a moderator

Re: Call Chain Completion - Limiting Search Space [message #761958 is a reply to message #761927] Wed, 07 December 2011 10:41 Go to previous messageGo to next message
Deepak Azad is currently offline Deepak AzadFriend
Messages: 543
Registered: July 2009
Senior Member
On 12/7/2011 3:20 PM, Marcel Bruch wrote:
> this is the beginning of a series of questions/design decisions regarding a call chain completion engine for/based-on JDT
Marcel, the right place to discuss implementation details for a patch on
JDT is bugzilla. Two reasons
- It is easier to keep track of decisions made during the
implementation. E.g. if someone wants to see a year later why a
particular feature was implemented in a given manner.
- Not every committer may monitor newsgroups, and bugs tend to more
attention in any case. For example, Dani is the content assist expert in
the team and it would be useful to get his views on implementation details.

Let's continue this discussion in bugzilla.

--
Deepak Azad
http://wiki.eclipse.org/JDT/FAQ
Re: Call Chain Completion - Limiting Search Space [message #761964 is a reply to message #761958] Wed, 07 December 2011 11:01 Go to previous message
Marcel Bruch is currently offline Marcel BruchFriend
Messages: 289
Registered: July 2009
Senior Member

https://bugs.eclipse.org/bugs/show_bug.cgi?id=365866
Previous Topic:Access to ActionBarAdvisor
Next Topic:QuickFixProcessor performance (profiling)
Goto Forum:
  


Current Time: Fri Mar 29 09:24:53 GMT 2024

Powered by FUDForum. Page generated in 0.01352 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top