Eclipse Community Forums: EMF » Unset on isMany containment-ref doesn't trigger detachment

Home » Modeling » EMF » Unset on isMany containment-ref doesn't trigger detachment

Unset on isMany containment-ref doesn't trigger detachment [message #1075325]

Mon, 29 July 2013 04:38

Eclipse User

Calling unSet on a single-valued containment ref triggers detachment. Calling unSet on a many-valued containment ref does not, leaving the previously-referenced objects in limbo.

Why the difference?

Thanks
--
Caspar

[Updated on: Mon, 29 July 2013 04:40] by Moderator

Re: Unset on isMany ref does not trigger detachment [message #1075344 is a reply to message #1075325]

Mon, 29 July 2013 05:07

Eclipse User

Caspar,

Comments below.

On 29/07/2013 10:38 AM, Caspar De Groot wrote:
> Calling unSet on a single-valued containment ref triggers detachment.
> Calling unSet on a many-valued containment ref does not, leaving the
> objects that were previously referenced from the feature in limbo.
A generated eUnset just does getAbcs().clear() and that's implemented to
handle inverse removals in
org.eclipse.emf.common.notify.impl.NotifyingListImpl.clear() so I'm
doubtful of your assertion because such a problem would have been
noticed many years ago. Not only that, when stepping through this logic
in the debugger just now, I see that it's working as expected, i.e., the
contained objects have their eContainer set to null.
>
> Why the difference?
I don't think there is a difference but I can look at a test case that
reproduces the problem if you provide one.
>
> Thanks
> --
> Caspar

Re: Unset on isMany ref does not trigger detachment [message #1075370 is a reply to message #1075344]

Mon, 29 July 2013 06:07

Eclipse User

Hi Ed,

Thanks for your quick response.

I should have mentioned that I'm invoking eUnSet reflectively.

Your point about the *generated* eUnset made me realize
I have none; which then made me realize the ref actually has
unsettable=false in my model. But so does the single-valued
containment ref I was testing.

So, my mistake.. but I do still wonder why the behavior isn't
the same, and why the setting delegate doesn't detect
the attempt to unset a non-unsettable feature.

Thanks

--
Caspar

Re: Unset on isMany ref does not trigger detachment [message #1075391 is a reply to message #1075370]

Mon, 29 July 2013 06:51

Eclipse User

Caspar,

Comments below.

On 29/07/2013 12:07 PM, Caspar De Groot wrote:
> Hi Ed,
>
> Thanks for your quick response.
>
> I should have mentioned that I'm invoking eUnSet reflectively.
I assumed that...
>
> Your point about the *generated* eUnset made me realize
> I have none;
Reflective delegation?
> which then made me realize the ref actually has
> unsettable=false in my model. But so does the single-valued
> containment ref I was testing.
Unsettable just means there's an extra state to distinguish having just
the default value as opposed to having been explicitly set to a value
that happens to be the same as the default value. For many-valued
features, that means you'd have to call clear on the list for eIsSet to
return true. In no case does it mean you can't unset the feature...
>
> So, my mistake.. but I do still wonder why the behavior isn't
> the same, and why the setting delegate doesn't detect
> the attempt to unset a non-unsettable feature.
It doesn't mean what you assumed. Unless the feature is changeable
false, it's always possible to unset the feature.
>
> Thanks
>
> --
> Caspar

Re: Unset on isMany ref does not trigger detachment [message #1076373 is a reply to message #1075391]

Wed, 31 July 2013 05:17

Eclipse User

[quote title=Ed Merks wrote on Mon, 29 July 2013 06:51]

>> Your point about the *generated* eUnset made me realize
>> I have none;

> Reflective delegation?

Yes.

> Unsettable just means there's an extra state to distinguish having just
> the default value as opposed to having been explicitly set to a value
> that happens to be the same as the default value.

So this distinction only affects the return value of the isSet
method? It has no bearing on eUnset at all?

But then if a feature has unsettable=false, what is the correct
isSet behavior? To always return true? Or is isSet undefined for
features that have unsettable=false?

> It doesn't mean what you assumed.

That's for sure Wink

Thanks again.

--
Caspar

Re: Unset on isMany ref does not trigger detachment [message #1076389 is a reply to message #1076373]

Wed, 31 July 2013 05:51

Eclipse User

Caspar,

Comments below.

On 31/07/2013 11:17 AM, Caspar De Groot wrote:
> [quote title=Ed Merks wrote on Mon, 29 July 2013 06:51]
>
>>> Your point about the *generated* eUnset made me realize
>>> I have none;
>
>> Reflective delegation?
>
> Yes.
>
>> Unsettable just means there's an extra state to distinguish having
>> just the default value as opposed to having been explicitly set to a
>> value that happens to be the same as the default value.
>
> So this distinction only affects the return value of the isSet
> method? It has no bearing on eUnset at all?
Yes.
>
> But then if a feature has unsettable=false, what is the correct
> isSet behavior? To always return true? Or is isSet undefined for
> features that have unsettable=false?
In general there are the following expectations.

* When you first create an EObject x, x.eIsSet(f) will be false for
each f in x.eClass().getEAllStructuralFeatures().
* After you call x.eUnset(f), x.eIsSet(f) will be false.
* After you call x.eSet(f, value), the value of x.eIsSet(f) depends on
whether f is an unsettable feature. If f is unsettable then it will
be true, if f is not unsettable, then it will be the same as testing
(value == null ? f.getDefaultValue() == null ?
value.equals(f.getDefaultValue()).

So the difference between unsettable features and non-unsettable
features is that for unsettable features there is one more state than
can be represented with only the values of the type. You'll see in
generated models, that's an extra boolean or an extra bit flag, in
dynamic/reflective models in the settings array, it's a special marker
value not from the data type. So unsettable features are always eIsSet
true after a call to eSet and false after a call to eUnset. For normal
(non unsettable features), eIsSet depends purely on whether the current
value of the feature is equal to the default value for the feature, so
calling eSet or eUnset will not change the state if you set to a value
equal to the default, or unset when it already had the default value.
>
>> It doesn't mean what you assumed.
>
> That's for sure ;)
> Thanks again.
>
> --
> Caspar
>

Re: Unset on isMany ref does not trigger detachment [message #1076452 is a reply to message #1076389]

Wed, 31 July 2013 08:19

Eclipse User

Hi Ed,

That's a thorough explanation, I really appreciate it.

Thanks a lot

--
Caspar

Previous Topic:	Customizing conext menu
Next Topic:	[Solved] URI reference between XMI files

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Jul 16 13:56:02 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter