Re: [recommenders-dev] Completion engine for annotation string parameter

[Marcel Bruch <marcel.bruch@xxxxxxxxx>]

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-
>>> _______________________________________________
>>> recommenders-dev mailing list
>>> recommenders-dev@xxxxxxxxxxx
>>> http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>> 
>> Thanks,
>> Marcel
>> 
>> --Eclipse Code Recommenders:
>> w www.eclipse.org/recommenders
>> tw www.twitter.com/marcelbruch
>> g+ www.gplus.to/marcelbruch
> _______________________________________________
> recommenders-dev mailing list
> recommenders-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/recommenders-dev