Record and annotation values

[Brian Goetz]

> I agree, i do not think it's a good idea to introduce record as annotation value just because we can but that's not the reason why i think we should introduce record as annotation value.
>
> There is a lot of time where you can construct an annotation with invalid values but those invalid annotation will not be catch at compile time but at runtime.
> By example,
>    @Test({ignore=false, timeout_value=-3, timeout_unit=SECOND})
>
> So having a way to specify a contract for annotation values will make Java more safe.

This is why it is best to start with problems first, rather than 
solutions.  It was far from obvious that this was your underlying 
motivation, and given this motivation, its far from obvious this is the 
best way to get there.

So let's start over: the problem you're trying to solve is that there is 
not a good way currently to do compile- or run-time annotation validation?

> yes, a specfic attribute is perhaps a better,
> i wonder if the information in the RecordSignature should not be part of the Extractor.
>

I think the containment here is backwards.  An extractor is a 
lower-level mechanism for implementing conditional deconstruction, which 
includes pattern matching.  A class can have multiple extractors 
(patterns), just as it can have multiple constructors. Records have a 
distinguished extractor (the primary deconstructor pattern), just as 
they have a distinguished constructor.  It should be possible to 
reflectively navigate from a record class to its primary ctor/dtor.  
That might be by referring to them from the RecordSignature, or might be 
some other way (e.g., an invariant that you can use the record signature 
as an input to findConstructor / findDeconstructionPattern.)