-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
If and how to represent Annotations in M3 #13
Comments
Is it right that we need to introduce these constraints?
|
I think yes
I'd say |
Good point. I guess we could allow references to Annotation, but I have not a strong opinion on this and I would be curious to hear what others think |
I think annotations are quite different beasts from the other subtypes of |
.... and otherwise make them concepts, right? |
Have we concluded that Annotation cannot be used as the target of references? |
I think there is little reason for annotations to be defined at the M3 level. Annotations can simply be defined in a separate language at the M2 level. Annotations are then just concepts, like any other concepts and they can use inheritance, interfaces etc just like in any other language.
The reference in this solution is always from the annotation to the annotated concept, which I think is conceptually correct. Whether we expect annotations to show in an editor together with the annotated concept or separately is purely an editor/tool issue. Both options can be supported, even within the same editor/tool. In the use cases above both options are being used. I see no benefit from creating a separate M3 notion of Annotation because:
The solution of having separate annotation languages at the M2 level is a combination of alternative A (represent annotations as concepts) and alternative B (separate annotations out in a separate model). The "con" at alternative B that it did not work out in practice is disputable. At Mendix we used a separate annotation model for defining version annotations attached to concepts, which worked very well. And in Freon we also use separate annotation model for editor definitions etc., which also works fine. Gives this I am strongly in favor of not adding Annotation to the M3 level. |
If I understand correctly, this is on M2 level: The AnnotationConcept (e.g. On M1 level, we need the opposite direction: For each
The quoted con argument also relates to M1: In GMF, it was very hard to keep the "annotations" to ecore instances (kept in genmodel, gmfgraph, gmftool, ... models) in sync. |
Decision via Slack vote on 2023-08-04: Alternative D: First-class citizen in M3, subtype of Classifier |
Do we want
Annotation
s, and how to represent them in M3?See also: #11, #12
What is an annotation?
[1] "limited" because the more complex the annotation is, the more likely it should not be part of the annotated node's lifecycle -- We might want to reuse the complex annotation somewhere else.
Example: In MPS, the editor of a concept can be seen as an annotation of that concept. But even if we deleted the concept, we might want to reuse the editor for another (similar) concept.
Use cases
But: Might want to store somewhere else for version control reasons
java.math.BigInteger
; for C#, generate toSystem.Numerics.BigInteger
Representation in M3
Alternative A: Just represent them as regular
Concept
sPro:
Con:
Annotation
s are always tied to the annotated node;Concept
s can be used on their own (or misused if they represent annotations)multiple
flag?Alternative B: Separate them out into adjacent model
example: EMF ecore vs. genmodel
Pro:
Con:
Alternative C: First-class citizen in M3, separate from
Classifier
; don't support containmentPro:
node.annotations
can only be ofAnnotation
typeCon:
Classifier
structure, e.g. supertype, featuresAlternative D: First-class citizen in M3, subtype of
Classifier
Pro:
Classifier
Con:
node.annotations
return type?? Don't understand thatConcept
Alternative E: Specialization of
Concept
Pro:
Concept
Con:
Annotation
can never be a partition, so inheritedpartition
flag is uselessAnnotation
andConcept
can onlyextend
their own kind OR we allow that mixture.The mixture is weird if used but not a structural problem.
Alternative F: Marker interface in builtin library
Does not work, as the concept that implements
IAnnotation
would need to instantiate it, i.e. fillIAnnotation
's features with concrete values.Pro:
Con:
IAnnotation
) can appear everywhere, even in regular structureAlternative G: Separate M3 language, similar to derived model
Annotations are “just” a derived model (as e.g. type system). Each client can request them the same way as any other derived model.
Difference: Annotations are stored, type system is calculated.
This would break our assumption: “Derived model can be reconstructed from original model”.
Pro
Con:
--> Would need an active repository, or a processor
This could be implemented as a “adjacent annotation” processor implementing annotations as separate models
The text was updated successfully, but these errors were encountered: