Record and annotation values
Brian Goetz
brian.goetz at oracle.com
Mon Apr 9 13:30:07 UTC 2018
> 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.)
More information about the amber-spec-experts
mailing list