GUI annotations are not inherited correctly

[Francesco Casella]

Please consider the attached test package. The DataType record has a defaultComponentName and a defaultPrefixes annotation. The MyData record extends DataType, so it should also have them.

However, if I open M and drag and drop DataType into it, I get the correct name and prefix, while if I drag and drop MyData I get the default name and no prefixes.

I tried to flatten MyData with both OF and NF, using --showAnnotations, but I didn't see the annotation in either case. According to Sect. 7.1 of the Specification

The elements of the flattened base class become elements of the flattened enclosing class, and are added at the place of the extends-clause: specifically components and classes, the equation sections, algorithm sections, optional external clause, and the contents of the annotation at the end of the class.

I guess the underlying API suffers the same issue. I'm not sure whether it just needs to be fixed in the NF or if the API shoud also be fixed.

[Per Östlund]

You forgot to attach something.

However, one issue is that the specification doesn't really say how annotations should be inherited. What does it mean to add the contents of the annotation at the end of the class?

There's also the section about graphical annotations, 18.6, which states:

First baseclass contents is drawn according to the order of the extends-clauses, and then graphical primitives are drawn according to the order such that later objects can cover earlier ones.

This seems to suggest that at least the graphical annotations shouldn't simply be merged like modifiers, since merging would cause the order of inherited annotations to be lost.

[Francesco Casella]

Replying to perost:

You forgot to attach something.

Done, sorry :)

However, one issue is that the specification doesn't really say how annotations should be inherited. What does it mean to add the contents of the annotation at the end of the class?

In the use case of the attachment, it seems pretty obvious to me. You have a base class defining a data record, and then you derive actual data records deriving from it and adding modifiers with actual values. When you drag and drop the data records into a model, they should be automatically declared as parameters. Why should you re-add the defaultPrefixes annotation on each derived data record? That's really awkward.

In this case the derived record has no annotation at all, so inheriting the annotations from the base class is absolutely straightforward.

There's also the section about graphical annotations, 18.6, which states:

First baseclass contents is drawn according to the order of the extends-clauses, and then graphical primitives are drawn according to the order such that later objects can cover earlier ones.

This seems to suggest that at least the graphical annotations shouldn't simply be merged like modifiers, since merging would cause the order of inherited annotations to be lost.

True. I guess we need to make progress on the MAP-LANG discussion item ​#2314. So far we mainly had Hans raising new questions. We should try to come up with a proposal :)

[Per Östlund]

Ok, I'm changing the ticket to the interactive API in that case, since "fixing" this in the NF wouldn't change OMEdit behaviour at all.

What needs to be fixed is rather API calls such as getDefaultComponentName and getDefaultComponentPrefixes (need to check which calls OMEdit actually uses to fetch the information). Those calls currently just checks the annotation of the given class without doing any instantiation whatsoever, so they need to be changed to also look in the base classes.

Doing so efficiently might require using the NF, but inheriting annotations in such a way that they're visible in the flat model is not required for that. It's more efficient to just look in the base classes if the parent class doesn't have the annotation, than to merge everything and then check the annotation.

[Francesco Casella]

Replying to perost:
Sounds good. I guess this could also be the case for experiment annotations.

[Martin Sjölund]

So that's isExperiment and the corresponding getter. Note that we tend to run isExperiment on every single class in package so it needs to be very fast :)

[Francesco Casella]

We'll try to sort this out in 2.0.0