Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] Completion engine for annotation string parameters?

Hi all,

Joscha, thanks a lot for the detailed thoughts. You're right, as it
probably won't be used very much (in case of the SupressWarnings).
Regarding other annotations, I'll have to think about, but out of hand
none come to mind immediately.

Greetings
-Sascha-

Am 05.04.12 13:57, schrieb Marcel Bruch:
> After reading Joscha's comprehensive reply:
> 
> I think it really makes sense to figure out how often the use case
> actually occurs. Sascha, any ideas on that? How many annotations are
> you aware aside supresswarnings ?
> 
> 
> 
> On 05.04.2012, at 12:47, Joscha Drechsler wrote:
> 
>> I have already thought a little about how it could be possible to
>> provide content assist for annotation parameters, but i haven't
>> come up with a feasible idea yet because i was thinking in broader
>> terms:
>> 
>> First, to address your SuppressWarnings use case: While it would
>> probably be possible to provide a content proposal handler, for
>> example in form of a quickassist, for adding SuppressWarnings
>> parameters, i don't think that this usecase is a good choice. The
>> way a SuppressWarnings annotation is usually added (assuming you
>> work with eclipse) is by using quickfix on an already existing
>> warning. This automatically creates the annotation with the
>> required string(s) as parameter. You usually don't just take your
>> code, write @SuppressWarnings and then trigger content assist to
>> propose a list of possible warning types to ignore. I can't think
>> of a reason why you would want to suppress the most popular warning
>> categories preemptively, so this feels like a bad approach.
>> 
>> The basic idea however is of course valid. Annotations often have
>> parameters, such as @Retention(RetentionPolicy.RUNTIME) and some
>> form of content assist for them would be nice. Often however, there
>> are more complicate parameter expressions: javax.persistence
>> annotations often make use of actual key-value-pairs instead of the
>> @Annotation(X) shorthand for @Annotation(value=x). For instance
>> there's @Column(name="columnName", nullable=false, length=123).
>> Also, the values for every parameter can be arbitrary java
>> expressions, including strings (cf. @SuppressWarnings), enum
>> constants (cf. @Retention above), class instances (cf.
>> @RunWith(Parameterized.class) in junit), arrays (cf.
>> @SuppressWarnings({"unused", "rawtypes"}) for multiple categories)
>> and even constant values calculated through actual formulas are
>> valid. For instance, you could write length=100 + FINAL_INT_FIELD
>> in the @Column example, if your FINAL_INT_FIELD has a fixed value
>> that can be calculated at compile time.
>> 
>> A proper content assist for annotation parameters would probably be
>> twofold:
>> 
>> First, you'd probably want to put an ordering on the list of
>> possible parameters. Eclipse already knows those (e.g. when write
>> @Column() and you ctrl+space inside the parenthesis, it gives you a
>> list of all available parameters in alphabetical order), but the
>> complete doesn't work properly because it just inserts to
>> @Column(nullable<cursor>) instead @Column(nullable=<cursor>). So
>> applying the standard "most people have used X" principle here
>> should work.
>> 
>> Second, when you are at @Column(nullable=<cursor>), you want to be
>> able to fill these values with content assist. This is something
>> that doesn't really work well in Eclipse at all currently, as it
>> just proposes your classes fields, not even caring whether they are
>> final, so almost every completion proposal results in a guaranteed
>> compile error when applied. Now, the type of the parameter you want
>> to complete becomes important: If it is an enumerable type (such as
>> an enum or boolean), you can easily propose applicable values
>> including a popularity ranking. With arrays of enumerable values,
>> such as @Target({ElementType.METHOD, ElementType.FIELD}), this
>> becomes a bit more interesting, but is probably still managable
>> through a quickassist handler. But, with not enumerable types, like
>> String or int, this becomes a real issue though.
>> 
>> Of course it would be possible to make a "most used" list of the
>> syntax expressions used as values and take proposals of that list.
>> That might work for SuppressWarnings, and with a bit of luck for
>> commonly used Column types in @Column(columnDefinition="CLOB NOT
>> NULL"), but i'm not too sure if you really want to do that. The
>> only annotation, I can think of, that actually reuses strings from
>> a fixed set (where you would usually use enum constants instead),
>> is SuppressWarnings. But, since the set of supported warning
>> categories differs from compiler to compiler, it doesn't use an
>> actual enum. Most other string parameters, such as @Column(name=x),
>> just use arbitrary strings I think. I haven't run any statistics on
>> that yet, so I can't provide concrete numbers here. But it does
>> feel like it requires a lot of time for only very little benefit.
>> For these non-enumerable values it might be the best to just
>> provide the normal content assist, like when you write String x =
>> <ctrl+space inside a method, only restricted to final fields,
>> possibly including ranking based on popularity.
>> 
>> Lastly, to make this thing a tad more intelligent, you would
>> probably want to give it enough brain to conclude, that when an
>> annotations only possible parameter is "value", it should skip the
>> first step of inserting the parameter name and immediately propose
>> possible parameter values. Otherwise, you'd end up with
>> @Annotation(value=X) everywhere and the @Annotation(X) shortcut
>> would never be used, which might confuse some people because that's
>> likely to be inconsistent with documented usage examples. But that
>> is an issue secondary to actually getting the content proposal to
>> work in the first place.
>> 
>> End of brain dump. Thoughts? Are there other annotations that
>> re-use string parameters? or maybe annotations with int parameters
>> with possible values predefined as static constants on a helper
>> class such as SWT.NONE, SWT.LEFT etc. flags?
>> 
>> Regards, Joscha
>> 
>>> That sounds like a nice addition :)Joscha, any ideas on that?
>>> (hope he's on the list) This sounds somewhat related to your
>>> annotation mining approach.Sascha, can you imagine to assist on
>>> data collection and implementation? Best, Marcel On 05.04.2012,
>>> at 09:08, Sascha Vogt wrote:
>>> 
>>>> Hi all, As I'm currently working on a bunch of compiler
>>>> warnings, from time to time I have to fall back to the
>>>> @SurpressWarnings annotation. While working with that, I
>>>> thought it would be cool to have code completion for the
>>>> allowed strings in that annotation. I know there is no "formal"
>>>> way to get the list of supported strings, therefore I thought
>>>> it might be cool to have a list of most used strings for a
>>>> given annotation. What do you think about such a feature. I
>>>> know, there is quite some thinking to be done here (obviously
>>>> one don't want to give a proposal for a "name" or "id"
>>>> parameter. Maybe the proposal only gets added if one string
>>>> occured more than 5? times or something like that). Greetings 
>>>> -Sascha-


Back to the top