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.)

Reply via email to