Re: [jdt-core-dev] Completion API modifications to propose expected type

[Jerome Lanneluc <jerome_lanneluc@xxxxxxxxxx>]

Another approach would be to pass the completion context in beginReporting:
requestor.beginReporting(completionContext or null);
requestor.accept(p1);
...
requestor.accept(pN);
requestor.endReporting();

Of course I have no idea if this is technically feasible...

Jerome

jdt-core-dev-admin@xxxxxxxxxxx wrote on 03/14/2005 07:39:04 PM:

> 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
> >
> >
> _______________________________________________
> jdt-core-dev mailing list
> jdt-core-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/jdt-core-dev