Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Strange behaviour of container feature setters
Strange behaviour of container feature setters [message #497921] Fri, 13 November 2009 14:49
Carsten Reckord is currently offline Carsten ReckordFriend
Messages: 139
Registered: July 2009
Senior Member
Hi all,

I have a question about an - at least for me - rather unexpected behaviour of container setters in the eclipse UML2 implementation. A
typical such setter looks like this (Property.setClass_):

public void setClass_(org.eclipse.uml2.uml.Class newClass) {
if (newClass != eInternalContainer()) {
//remove from old container
//add to newClass if newClass != null

As you can clearly see, newClass is not compared to the current value of the feature (Property.getClass_()), but to the current container,
whatever feature that might come from. This leads to two problems:

1) If newClass==eInternalContainer(), but the current container feature is not Property.class_ (okay, in this concrete example there is no
other container feature with a type that makes this possible), the desired change of the container feature is discarded silently. I think
expected behaviour would be to remove the property from its current container and add it to the correct containment feature.

2) If newClass==null, eInternalContainer()!=null, BUT getClass_()==null (i.e. we currently have a container, but it's not the class_
feature, but e.g. the owningTemplateParameter feature), the Property is removed from the other container regardless. Expected behaviour in
this case would be that nothing changes, since getClass_() is already null.

To sum it up, I would have expected a correct implementation to be more along the line of

public void setClass_(org.eclipse.uml2.uml.Class newClass) {
if (newClass != eInternalContainer() && (newClass != null || eContainerFeatureID() == UMLPackage.PROPERTY__CLASS)) {
//remove from old container
//add to newClass if newClass != null

Since the current implementation is found in some variations throughout the model however, I was wondering if the current behaviour should
for some reason be considered expected behaviour or if it's actually a bug?

Previous Topic:RSM 7.5 exports EMF UML2 XMI v3.x instead of v.2.x
Next Topic:Strange behaviour of container feature setters
Goto Forum:

Current Time: Sat Jun 23 10:43:37 GMT 2018

Powered by FUDForum. Page generated in 0.01857 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top