On Tue, 7 Feb 2023 12:59:32 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> Still, there seems to be a modelling issue here. The property of "where >> could this attribute go" is a property of the attribute. Of course, for >> usability reason, an AttributedElement might expose a predicate saying "I >> only accept attributes of these kinds". But it seems to me as if the API has >> this relationship backwards, due to _where_ the Kind interface is being >> defined. I think if `Kind` was defined in `AttributeMapper` it would be a >> tad easier to understand. And, perhaps, the `attributedElementKind` name >> should be changed to something like `applicableAttributeKinds` or something >> like that. > > The relation is that each `Attribute` is applicable in N `AttributedElements` > and not vice versa. > For example `ClassModel::attributedElementKind` returns `CLASS` and for > example > `Attributes.RUNTIME_INVISIBLE_TYPE_ANNOTATIONS::applicableAttributeKinds` > returns `Set.of(CLASS, METHOD, FIELD, CODE_ATTRIBUTE, RECORD_COMPONENT)`, so > we know it is applicable. > > However I'll try to re-visit this part of API if needed at all. I understand what the API, in its current form, wants to do. IMHO, the same functionality would be better expressed if the API had a way to say: * each attribute has a _target_, where target can be a set of CLASS, METHOD, ... * an attribute mapper supports a set of attribute targets * an attributed element also supports a set of attribute targets E.g. the target of the attribute is the concept to model - then AttributeMapper and AttributedElement just happen to expose a set of supported targets, which clients can query if needed. ------------- PR: https://git.openjdk.org/jdk/pull/10982
