How does EcoreUtil.delete() handles objects that are keys in a EMap? [message #1384969] |
Tue, 03 June 2014 11:07 |
Silvestre Martins Messages: 84 Registered: July 2009 |
Member |
|
|
The implementation of a EMap is used using a special class that represents the entry in the map, which has 2 attributes: the key and the value.
My question is: does the EcoreUtil.delete() handles the automatic removal of the entry in the map when an object that that represents the entry key gets deleted, as it happens with the regular EList?
From what I could observe, it seems not - while the key is set to null, the entry and the value remains untouched, which causes the data to not be disposed.
Moreover, this also violates the usage of keys in the Maps, since the key should be immutable, otherwise it would not be possible to access that entry anymore if the key changes, since hashCode() and equals() won't return the same anymore.
Am I right about this analysis?
|
|
|
Re: How does EcoreUtil.delete() handles objects that are keys in a EMap? [message #1384971 is a reply to message #1384969] |
Tue, 03 June 2014 11:37 |
Ed Merks Messages: 33113 Registered: July 2009 |
Senior Member |
|
|
Silvestre,
Comments below.
On 03/06/2014 1:07 PM, Silvestre Martins wrote:
>
> The implementation of a EMap is used using a special class that
> represents the entry in the map, which has 2 attributes: the key and
> the value.
>
> My question is: does the EcoreUtil.delete() handles the automatic
> removal of the entry in the map when an object that that represents
> the entry key gets deleted, as it happens with the regular EList?
No. In fact any changes to the map's keys are problematic at best. The
key could even be multi-valued so delete could remove one of the
EObjects in the list; that wouldn't play nicely either.
>
> From what I could observe, it seems not - while the key is set to
> null, the entry and the value remains untouched, which causes the data
> to not be disposed.
Yes.
> Moreover, this also violates the usage of keys in the Maps, since the
> key should be immutable,
Yes, another problem is if the object should ever be converted to a
proxy and needs to be resolved again; that would also change the key and
hence corrupt the hash indexing.
> otherwise it would not be possible to access that entry anymore if the
> key changes, since hashCode() and equals() won't return the same anymore.
Indeed.
>
> Am I right about this analysis?
Yes, it's problematic. It would also be problematic to simply remove
the entry, because the value could be a containment reference as well,
and then all that stuff would need to be deleted. And it's possible
(though unlikely) for there to be references to the map entry itself...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03246 seconds