New annotations to specify expected argument values and return values?

Esp. now that external annotations are possible it would be nice to be able to do this:

public void JDialog.setDefaultCloseOperation(@IntValues({WindowConstants.HIDE_ON_CLOSE, WindowConstants.DO_NOTHING_ON_CLOSE, WindowConstants.DISPOSE_ON_CLOSE}) int operation);

Idea could then automatically do
- really smart code completion
- inspections, e.g. "EXIT_ON_CLOSE" is not allowed for that parameter

I guess there would have to be different annotations for different parameter types.
Also it would make sense to have a "strict" flag at the annotation, because some value (e.g. thread priority) have constants defined for common values, but others are allowed, too.
Finally min,max specification would also make sense.

What do you think?

3 comments
Comment actions Permalink

As for completion, I was thinking about such a thing some time ago. But
my thoughts related only expected type, namely, the ones for Map.get(),
Collection.remove(), Collection.contains() and so on. In the end I've
just hardcoded these methods, and now smart completion preselects the
values of needed type, not just any Objects. And as for specifying
values... Interesting idea. But don't you find that we would have really
lots of such annotations? Won't it be too clumsy?

And explain, please, what do you mean by 'strict' attribute? Now I think
that smart completion should show everything that suits by type, but
have smart item preference policy. Do you really suggest to exclude some
otherwise suitable variants from the list just because they're not
mentioned in the annotation? Won't there be anyone who will protest?

0
Comment actions Permalink

Yeah, we would probably have lots of such exceptions, but they would mostly be external annotations applying to libraries (for all those pre-1.5-methods in JDK that do not use enums) so you won't probably see at all them while coding.
New code will mostly be better of using enums or full blown classes.

With "lax" I was mostly refering to the inspection that uses the annotations.
For example we could specify that the priority argument of Thread.setPriority()
- can take the values MIN_PRIORITY, NORM_PRIORITYand MAX_PRIORITY
- but this set is lax, so other values are allowed also
- but in any case the allowed minimum is MIN_PRIORITY and the maximum is MAX_PRIORITY

The inspection could then flag an error if 999 is used as argument and another inspection could tell you that it would be nicer if you use NORM_PRIORITY when calling the method rather than using the literal 5 directly.

In contrast the set of values for JDialog.setDefaultCloseOperation() is strict, so an error should be flagged if another value is used.

I really think that smart completion for strict value sets should only show the defined values. Why would anyone protest if using another argument would only result in an exception at runtime?

In fact I already implemented the inspection part some time ago (using xml files for "annotation" stprage because external annotations were not implemented then).
I gave up when trying to customize completion, because I never managed to do what I wanted: http://www.intellij.net/forums/thread.jspa?messageID=5145274&#5145274

0
Comment actions Permalink

New code will mostly be better of using enums or full blown classes.

Sorry, I don't understand what you mean.

With "lax" I was mostly refering to the inspection that uses the annotations.
For example we could specify that the priority argument of Thread.setPriority()
- can take the values MIN_PRIORITY, NORM_PRIORITYand MAX_PRIORITY
- but this set is lax, so other values are allowed also
- but in any case the allowed minimum is MIN_PRIORITY and the maximum is MAX_PRIORITY

The inspection could then flag an error if 999 is used as argument and another inspection could tell you that it would be nicer if you use NORM_PRIORITY when calling the method rather than using the literal 5 directly.

OK, got it.

I really think that smart completion for strict value sets should only show the defined values. Why would anyone protest if using another argument would only result in an exception at runtime?

Don't know, just suppose.

In fact I already implemented the inspection part some time ago (using xml files for "annotation" stprage because external annotations were not implemented then).
I gave up when trying to customize completion, because I never managed to do what I wanted: http://www.intellij.net/forums/thread.jspa?messageID=5145274&#5145274

BTW, I'm also thinking about creating a pluggable API for completion,
but not in Selena. Any suggestions are welcome.


Maybe we'll continue this discussion in e-mail?

0

Please sign in to leave a comment.