Community
Participate
Working Groups
We should add an API on completion proposal API to surface the expected type when we had one in the engine.
Tom, this will allow use to get the rhs of an assigment to guess the type arguments for generics (e.g List<String> l= new ArrayList<???>)
Fixed. Added new completion API to describe context in which the completion occurs.<br> Currently only the expected types of the potential completion proposals are proposed. X x = zzz<complete here> In this example the expected type is <code>X</code>. It is not mandatory to a proposal to respect this expectation and it is possible that there is no completion proposal. /** * Completion context. * * Represent the context in which the completion occurs. * * @see CompletionRequestor#acceptContext(CompletionContext) * @since 3.1 */ public class CompletionContext { /** * Return signatures of expected types of a potential completion proposal at the completion position. * * It's not mandatory to a completion proposal to respect this expectation. * * @return signatures expected types of a potential completion proposal at the completion position or * <code>null</code> if there is no expected types. * * @see Signature */ public char[][] getExpectedTypesSignatures() {...} /** * Return keys of expected types of a potential completion proposal at the completion position. * * It's not mandatory to a completion proposal to respect this expectation. * * @return keys of expected types of a potential completion proposal at the completion position or * <code>null</code> if there is no expected types. * * @see org.eclipse.jdt.core.dom.ASTParser#createASTs(ICompilationUnit[], String[], org.eclipse.jdt.core.dom.ASTRequestor, org.eclipse.core.runtime.IProgressMonitor) */ public char[][] getExpectedTypesKeys() {...} } Client must override 'CompletionRequestor#acceptContext(..)' to know the context. This method call ocurs after the call to 'beginReporting()' and before the call to any 'accept(CompletionProposal)' method. public class CompletionRequestor { ... /** * Propose the context in which the completion occurs. * <p> * This method is called one and only one time before any call to * {@link #accept(CompletionProposal)}. * The default implementation of this method does nothing. * Clients may override. * </p> * @param context the completion context * * @since 3.1 */ public void acceptContext(CompletionContext context) {..} ... }
Why does the new API class CompletionContext have an internal class InternalCompletionContext as its superclass? The superclass has protected methods which are inherited by the API class, and would normally be considered API as well. However, CompletionContext is final, so there is 0 change that a client could use those method. Would it not be simpler simpler to get rid of InternalCompletionContext entirely?
Methods of InternalCompletionContext are not design to be API. InternalCompletionContext is not inside the same package of API class CompletionContext, so client can use this protected methods only inside the same package. But the package of InternalCompletionContext is an 'internal' not API package. If these methods are inside CompletonContext, then they would be public method inside an API class. In this case the only way to forbid access to these methods would be to add a comment /** this method is not API */. Move methods inside CompletionContext and add the comment would be better ?
I couldn'd find any internal callers of those methods on InternalCompletionContext. Are there any? If there are, what I suggest doing is change the protected methods on InternalCompletionContext to package-private so that they do not show up in generated Javadoc as being inherited.
These methods are called inside CompletionEngine.
Change the resolution to Fixed
Verified in I20050330-0500
