Conversation
- The utility method FeatureUtil.getCrossFeatureOf already did the correct computation and only needed to be called from the delegate.
|
I tested it with And them I could get: , and I found no major issues. |
|
I found only But in I do not think it's critical but showing feature chains would be more helpful to understand. |
|
I have one question on end features. We can also write ends without ReferenceUsage such as But I'm not so sure about the semantic differences. Is this model is relevant as well? |
For a binary connection, the first feature in the feature chains for cross subsetting is an actual end feature of the connection. That is the name being shown. For ternary and higher connections, the first feature in the feature chains for cross subsetting is a constructed "Cartesian product" feature without a name. So, neither feature in the feature chain has a name, and there is nothing to show. |
This PR updates the derived property computation for
Feature::crossFeatureto properly account for an implied cross subsetting.Change
Feature_crossFeature_SettingDelegate::basicGetwas updated to simply call the utility methodFeatureUtil::getCrossFeatureOf, which already computed thecrossFeaturecorrectly.Note
After analysis, it was decided that the above change was the only update necessary to handle implied relationships. With this change, the consistent rules for derived properties are:
getOwnedSpecializationsdoes not include implicit specializations, andgetOwnedMembersdoes not include implicit binding connectors.supertypesincludes supertypes via implied specializations andgetInheritedMembershipsincludes memberships inherited via implied specializations.To include implied relationships and binding connectors in all cases, call
ElementUtil.transformAll(root, true)to add them physically to the abstract syntax tree (the second argument is a boolean flag toaddImplicitElements.