Delete semantics

[bvssvni]

Editor::delete returns an object which references must be updated. This happens when you swap-remove the deleted item with the last one in the same table.

Before deleting an object, you should delete all references pointing to the old object. After deletion, you should update all references pointing to the returned object to point to the deleted id.

For example, if you have a table of 10 objects with object ids 0 to 9 and delete object 3, object 9 will be put in the same slot as 3. This means references pointing to object 9 must be updated to point to 3. Old references pointing to the old object 3 must be deleted before calling Editor::delete, or else they will point to the old object 9.

If the deleted object is at the end of the table, then the editor should not return an object to update references.

Delete a range of objects

When deleting a range of objects, it is only safe to do so if the ids are exclusive and none of them results in swapping one of the others that got deleted. Delete the objects in reverse order, starting with the highest id and working toward the lowest. Since a higher id can not result in swapping with one of lower id, it is guaranteed that none of the objects in the range will swap with each other.

However, there is a catch. If the range of objects is sequential, the first swap will result in another swap with the same object.

For example, if object 6-8 is deleted, object 9 will be put in same slot as 8, then it will be put in 7, then 6. The references pointing to the old object 9 should be updated to point to 6.

[bvssvni]

One problem with Editor::insert is that it is not reversible. The references that got deleted will not point to the same object when restored.

A solution could be to rename Editor::insert to Editor::add and then add Editor::insert which will swap the object at that location and put it at the end.

[bvssvni]

One problem is that updating references might be very slow, specially updating references pointing to an object.