[Checkers] Ideas for reducing verbosity of annotations
mernst at cs.washington.edu
Fri Jun 5 03:35:31 EDT 2009
> 1. What defaults daikon currently uses (e.g. do you mainly use NNEL
> nullness default?)?
> How/Why is applying different defaults in other classes relevant?
I meant copying down annotations from overridden methods.
> 2. For handling cases where method return null if nothing is found,
> how does Flow handle them?
Flow does a fine job. The only problem in that there are hundreds of
subclasses, and in every subclass, the implementation of the find method
has a @Nullable annotation on the return value, in the signature. I was
thinking about how to eliminate that.
> Comments on the new default schemes:
> > * syntactically containing elements (variable, method, class,
> > package)
> I assume that we are handling that.
> > * the overridden method declaration
> I think that this very useful especially if you have deep hierarchy.
> We should definitely go for it. However, personally, I prefer having
> an InheritQualifiers meta annotation, at least until we have a
> defaults tool.
As we mentioned in person, the number of annotations in the signature tends
to be small, so if you have to write anything, you might as well write the
real type qualifiers. Let's not implement @InheritQualifiers until there
is a compelling use case.
> > * the declaration of the type (whose qualifier we are trying to
> > determine)
> Do you have an idea of how helpful this is? Roughly how many
> annotations would it reduce?
DiscardInfo says why a given invariant was omitted from the output, or it
is null if the invariant wasn't omitted. It's the return value from some
of the find-like methods, which ask, "should this invariant be omitted";
the method returns null if the invariant should be retained. I have not
annotated all of Daikon, but in the parts that I have, every instance of
DiscardInfo is nullable (or is on a local variable). This proposal would
eliminate all those annotations. I should annotate the rest of Daikon to
see whether the pattern holds.
> For the tools:
> > * A tool that determines the current annotation on a given type.
> > This can
> > be looked up in the classfile (complication: flow-sensitive type
> > refinement), or written using the checker framework.
> This is a necessity I think if we support any more complicated default.
As you mentioned, it could be useful in a doclet as well.
> > * A tool that identifies all extraneous annotations (for instance, a
> > programmer write add a default and see how many annotations it makes
> > redundant).
This could also be useful as a code cleanup tool, even if the default is
> > * A tool that converts from one set of defaults to another,
> > adding/removing source code annotations as appropriate in such a way
> > that the semantics of the program is preserved (the effective
> > qualifier
> > on each variable remains the same).
> While these are useful (especially for us), I doubt that programmers
> once they annotate the codebase they would go back and spend time
> doing manual work to minimize the annotations.
I tend to agree. These would help us experiment with whether the defaults
are a good idea, but can be put off at least until the other defaults are
added, if not longer.
> I think that that the potential users are more concerned
> about actually manually writing a lot of annotations rather than the
> final number of annotations in the code. All of these tools (but the
> first) help the programmers reduce the number of final annotations but
> the programmer would still need to go over the first overhead of
> writing them.
Excellent point. The code completion IDE support is more true when writing
new code (with which we have less experience!) that when annotating
existing code (which is our mode right now).
Thanks for the good comments.
More information about the checkers