[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jdt-core-dev] Completion API modifications to propose expected types
|
I like 2) better. The only concern I have is that any acceptXXX method
seems to suggest that it can be called multiple times, and that the
accepted item is not dependent on other items (as with
accept(CompletionProposal)), but I can't think of a better name.
Javadoc should define the call sequence accordingly and state whether
acceptContext is always called (preferred) or may be omitted.
requestor.beginReporting
requestor.acceptContext (optional?)
requestor.accept(p1)
...
requestor.accept(pN)
requestor.endReporting
-tom
David Audel wrote:
To solve the bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=86970,
completion API needs to be modified.
I see several ways to solve the problem and propose expected types:
1) propose the expected type inside the proposal.
public class CompletionProposal {
...
/**
* Return the expected types of proposal.
*
* It's not mandatory to a completion proposal to respect this
expectation.
*
* @return the expected types of the proposal or
* <code>null</code> if there is no expected types.
*/
public char[][] getExpectedTypes() {...}
...
}
This API is easy to add but the same expected types are proposed for each
proposal.
2) propose the expected types only one time with a specific accept method.
public abstract class CompletionRequestor {
...
/**
* Propose the context in which the completion occurs.
* <p>
* The default implementation of this method does nothing.
* Clients may override.
* </p>
* @param context the completion context
*/
public void acceptContext(CompletionContext context) {
// do nothing by default
}
...
}
/**
* Completion context.
*
* Represent the context in which the completion occurs.
*
* @see CompletionRequestor#acceptContext(CompletionContext)
* @since 3.1
*/
public final class CompletionContext {
/**
* Return the expected types of a potential completion proposal at the
completion position.
*
* It's not mandatory to a completion proposal to respect this
expectation.
*
* @return the expected types of a potential completion proposal at the
completion position or
* <code>null</code> if there is no expected types.
*/
public char[][] getExpectedTypes() {...}
}
This API is better because the expected types are not specific to a
proposal and expected types can be known even if there is no proposal.
Moreover it would be easy to add other context information.
Some other information could be added to this API
/**
* Completion context.
*
* Represent the context in which the completion occurs.
*
* @see CompletionRequestor#acceptContext(CompletionContext)
* @since 3.1
*/
public final class CompletionContext {
/**
* Return the expected types of a potential completion proposal at the
completion position.
*
* It's not mandatory to a completion proposal to respect this
expectation.
*
* @return the expected types of a potential completion proposal at the
completion position or
* <code>null</code> if there is no expected types.
*/
public char[][] getExpectedTypes() {...}
/**
* Completed token
*/
public char[] getCompletionToken() {...}
/**
* Kinds of the potential proposals.
*/
public int[] getPotentialKinds(){...}
}
What do you think about this API ?
Do you see some other methods that could be useful ?
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
