Community
Participate
Working Groups
Objects, that are created on demand and referenced by a derived, transient, containment are not part of the eContents list. This may lead to unexpected behavior, e.g. the diagnostician will not validate these objects. OTOH it is very convenient that eContents does not change when someone processes and object's contents and thereby transparently creates new contained instances. If these instances were part of eContents, a concurrent modification would occur. Concrete use case in Xtext / Xbase: XFeatureCall has something like #implicitReceiver and #implicitFirstArgument. Both may be initialized when #getFeature is called and resolves a cross references since the #implicits carry additional information about the reason why #getFeature resolves to a specific instance.
I've changed it to filter out exactly for the same cases that non-containment references are filtered out for eCrossReferences. As long as the derivation is done during the first get, this approach to derived containment should work well. As long as no multi-valued feature's list is changing as we iterator over that specific list via eContents or eCrossReferences, we shouldn't see any concurrent modification issues. The changes are committed to CVS for 2.8.
The changes are available in builds.
