Adding Functionality to Insert Elements in an EReference at the Last Position

Currently, the recording of the insertion of an element into an EReference yields an InsertEReference which contains a newValue and an index. One of the most common cases is the insertion of an element at the end of the EReference in the case of which the index is equal to the number of elements in the EReference during the insertion. The resulting InsertEReference is then dependent on the correct number of elements in the EReference to be applied. This is espacially hindering in the case of the insertion of multiple elements at once. were the InsertEReferences from the recording have to be applied in the correct order and none of the InsertEReferences can be left out (except the last one).

An addition to this functionality should be implemented to allow for the manipulation of the order in which the InsertEReferences are applied and the deletion of certain InsertEReferences without loosing the applicability of the remaining InsertEReferences.

To give an example: Currently, inserting a list of elements [d,e,f] into an EReference which already contains the elements [a,b,c] returns a Sequence of InsertEReferences [insert(d, 4), insert(e, 5), insert(f, 6)]

The three insertions can be applied in this order only
Deleting an insertion makes the successing insertions unapplicable

A better version might be if the recording creates the following list: [insert(d, -1), insert(e, -1), insert(f, -1)] where -1 means "at the end of the EReference" or "at ereference.size()"

The three insertions can still be applied in this order but can be shuffled as well
Deleting an insertion does not effect the remaining insertions

I am planning to address this issue in a PullRequest in a timely manner.

I am not really sure about this change. Should this apply only for changes within the VSUM or also for changes propagated from some view? If it is a change in the VSUM, it solves -- as you said -- the problem that I can leave out changes of the sequence when constructing a view and still correctly insert the element. However, this only solves the problem for this one particular case: insertion at the end. An insertion at any other position could still not be handled if a change inserting an element at a lower index before is left out. Furthermore, would a change with a fixed index to append an element still be valid or do we require every such change to have the -1 index? The primer would introduce ambiguity to the change recording, the latter would make strong requirements about internals. If this should also apply for views, there arise even more questions. If I have in the VSUM the list [a,b,c] which is transformed in the view to [a,b] and now I insert an element at the last index, should the VSUM list be [a,b,c,d] or [a,b,d,c]. Obviously, from a view perspective, both solutions are valid, but I think we should first discuss such problems conceptually before implementing a solution which limits the solution space.

So in general, I think we should first solve this problem conceptually (or at least come up with an approach that has known and accepted limitations) before actually implementing one hot shot solution. Maybe the -1 index change is the best solution for this problem but for me there are too many open questions to answer this now.

Also I don't understand what you mean with that the order of changes can be shuffled. Sure, with the -1 index I could apply the changes but the result would be wrong (i.e. the elements are not in the recorded order anymore).

As far as I understand, there are two issues: First, the representation of a change that inserts an element at the last index of a list (no matter why this shall be done). Second, the monitoring of a change that shall be interpreted as being the insertion of an element at the last index of a list (or any other index in a projectional view).

First of all, having a representation for a change that inserts an element at the last index of a list, no matter how the list actually looks like, sounds reasonable to me, as appending to a list is a usual operation. I don't see a reason why we should not have that functionality if it is required to implement some other functionality (otherwise: YAGNI).

As @JanWittler explained, there is no unique answer how a change that inserts an element at the last index of a list (in a view) shall be interpreted, both in case the projectional view represents the complete list of an underlying model or because of leaving out elements in the view. While we can simply say that insertions at the last index are always interpreted as such (an e.g. represented with index "-1"), it is even worse for insertions that are not at the last index, as it is completely unclear where to insert the element in the underlying model. The only approximation that may be done is that it has to be inserted between the two elements from which the elements before and after the inserted element in the view have been projected.

One solution attempt I would see to support list modifications in views at all looks as follows:

Always consider insertions at the first index as "0" insertions
Always consider insertions at the last index as "-1" insertions
Allow insertions at other indices than the last and the first only for lists in which no elements have been filtered out when creating the view. Until the latter is implemented, we might simply disallow insertions into lists at the first or the last index.

However, I totally agree that we should first have a discussion collecting all kinds of situations in which list changes may be problematic (may it be propagating changes from a view to the underlying model, creating a projectional view by filtering changes in the underlying V-SUM or whatever) and find a holistic approach to support them. This could be a topic for the next or one of the next ConCalls.

Thank you for providing comments concerning this topic. @JanWittler, Thomas Kühn and I had a short meeting last Friday were we discussed the points you mentioned.

The first thing that I took with me from there is the issue with insertions into a view and how this should be translated back into the VSUM. As far as I understood, this is an issue that also exists without the "insertion at the last/ first index" and as you pointed out @HeikoKlare, that the case with such a functionality would currently be the most constrainted one compared to insertions at any other index. So from this site nothing speaks against having it, although this is of course not enough (as you referenced YAGNI)

Secondly, - this is something that Thomas wanted to point out - the insertion at minus one is already "supported" by the definition of the static NO_INDEX = -1 which can have a look at in the EMF docs or on GitHbu

Lastly, concerning YAGNI, this enhancement originated from research by @SofiaAnanieva. Although I am not 100% in the subject, I am pretty sure that the issue there was about relaxing the execution semantics for otherwise non-executable changes as I tried to outline above with my small example. Assuming that this research will be continued and integrated into Vitruvius, this enhancement seems to be needed in the future.

I prepared a pull request in my Vitruvius fork here but I have not opened an official pull request yet. If you want, you can have a look on the potential changes there as a foundation for further discussion on this topic.

vitruv-tools / Vitruv

Adding Functionality to Insert Elements in an EReference at the Last Position #512