[JSR308] array-valued annotations

[Tom Ball]

David Wagner wrote:
> Tom Ball writes:
>> It sounds like we are in agreement, but I prefer the term "contract" 
>> (from Eiffel's "Design By Contract") to "type" when using metadata to 
>> provide additional information to error-checkers regarding an API.  My 
>> guess is that the JSR's spec will be less confusing by keeping these 
>> concepts separate.
> 
> Well, I don't share that preference.  A type is not the same thing as
> a contract.  I prefer to use the term "contract" when it is right to do
> so, and the term "type" when that is right.  Some error-checkers work
> by methods that are better understood as type-checking than as anything
> having to do with Eiffel's "design by contract"; others, just the reverse.
> (For instance, a type-qualifier system like CQual or JQual would be a good
> example of something best understood in terms of types, not contracts;
> in comparison, something like JML is about contracts, not types.)

Of course I know types and contracts aren't the same thing (my project 
has been working closely with the javac team for the past two releases 
on their intermediate model).  My point was that a specification defines 
more than types, and I believe that notes to error checkers are part of 
a specification.  Types don't equal the specification, even though they 
are a major part of it.  If you believe that annotations can be used to 
define new types, then you are discussing a different language than Java 
as they are explicitly not allowed to do so by the JLS.  That is, unless 
you are also redefining how the JLS defines "type", which doesn't make 
much sense in the context of a JSR discussion.

I'm sorry I got your hackles up referring to Eiffel, and am not 
suggesting in any way that we implement DBC.  My references to contract 
are always lower-case, referring to the usage agreement a good 
specification outlines between a class's public design and its clients.

Tom