Community
Participate
Working Groups
Created attachment 251809 [details] Archive containing profile + model with applied profile Scenario (also see two models in attachment): * Create a profile * Import metaclass Class * Extend Class with Stereotype1 * Add a property Attribute1 with: - Type: a newly created Enumeration1 with two literals - Multiplicity: 0..1 * Define it * Create a UML model * Apply the profile created above * Create a Class diagram * Add a Class * Apply the Stereotype1 * Look at the tagged values Problem (s): * The tagged value is already filled with the first literal. This is strange. We didn't provide any default value. * There is no way (afaik) to remove the value (so Attribute1==null) Remark: I took the example of an Enumeration here, but the same problem exists for basic types such as UML's Integer. There the value is automatically 0 and no null can be assigned.
This is a consequence of the implementation of enumerations and primitives in EMF and Java. In Java, primitive fields/variables always have a value. They cannot be null (for that, the wrapper classes are required). And EMF implements the same semantics for enumerations: they are like primitives, always having a value. However, EMF also provides for a separate set/unset state of a property, dubbed "unsettable"-ness. Unset for primitives that have no explicit defaults could be interpreted as a null value, and an explicit unset action can return a property that was set back to unset state even when null cannot be assigned. But, that interpretation is application-specific. I don't think that it is something that Papyrus can impose. This issue has been raised before in the UML2 project in the context of both code generation and dynamic profiles. See, for example, bug 164095 which is resolved as "won't fix" with a statement that the Ecore profile should be used to tag properties as unsettable where needed. I doubt that Papyrus can do anything more than this.
One thing Papyrus could do, once the property is configured as "Unsettable", is to provide a button to actually unset it; and support the <<Unset>> value in the Combo Box
(In reply to Camille Letavernier from comment #2) > One thing Papyrus could do, once the property is configured as "Unsettable", > is to provide a button to actually unset it; and support the <<Unset>> value > in the Combo Box +1 But other primitives such as Integer, String don't have combo boxes. What to do for those?
> But other primitives such as Integer, String don't have combo boxes. What to do for those? Two options: An "unset" button for text fields, or a Magical <Unset> value. We used both already, and I think the <Unset> magical value is still used today (At least in the Papyrus properties view framework, which may not be used by the Profile tab)
