[
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
|
JDT Text plans to make the ResultCollector API . Please add your comments
to bug 84998. Besides that there are no further plans for 3.1.
Dani
"Max Rydahl
Andersen"
<max.andersen@jbo To
ss.com> jdt-core-dev@xxxxxxxxxxx
Sent by: cc
jdt-core-dev-admi
n@xxxxxxxxxxx Subject
Re: [jdt-core-dev] Completion API
modifications to propose expected
16.03.2005 14:02 types
Please respond to
jdt-core-dev@ecli
pse.org
Hi,
Concerning changes in CompletionRequestor and its friends...
has work started on making the Java completion easily available/extendable
and reusable in other contexts than the builtin java editor ?
-max
On Tue, 15 Mar 2005 16:27:56 +0100, David Audel <david_audel@xxxxxxxxxx>
wrote:
> It's technically feasible but CompletionRequestor#beginReporting() is a
> 3.0
> API.
> I think that's probably better to preserve the old beginReporting()
> method
> to avoid the deprecation of this method.
>
> David
>
> Tuesday, March 15, 2005 4:17 PM
> To: jdt-core-dev@xxxxxxxxxxx
> cc:
> From: Jerome Lanneluc/France/IBM@IBMFR
> Subject: Re: [jdt-core-dev] Completion API modifications to propose
> expected types
>
>
>
> 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
>
> _______________________________________________
> 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
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max@xxxxxxxxxxxxx
http://hibernate.org
JBoss Inc
max.andersen@xxxxxxxxx
http://jboss.com
_______________________________________________
jdt-core-dev mailing list
jdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/jdt-core-dev
