Better handling of shallow sets
johann-petrak opened this issue · 2 comments
- this is necessary so we can always have a different owner set in the detached set than in the attached set
- should be well documented: once an annotation gets moved in a detached set, it cannot be found by object id in the original set any more!
- Also document: since we use shallow copies, changing the feature will still change the features in the original set!
Also make sure we use the proper equality predicates depending on the situation:
- by default, equality is based on identity!
- In order to use content-based comparison we need to use ann1.equals(ann2) where all public attributes are compared using "==", including the features: this is ok, since Features inherits from UserDict which uses content-based comparison semantics
This is actually not a good idea: we want to be able to have the original annotations in detached sets. This is mainly because we might want to use annset.remove(ann) with an ann that comes from a detached set (e.g. one where we have selected based on type, overlap etc). This would not work if ann is a shallow copy.
The real issue is detached sets where annotations can come from more than one original set (as with doc.anns) or source, so annotation ids may clash. This then requires that a shallow copy be made with a new id.
So maybe we create from the original annotations whenever the input is a single set and we create the set from scratch.
With doc.anns(annspec) we always create copies if more than one input set is specified.
With incremental additions, all annotations added after the initial creation will be shallow copies.
The methods to create a detached set now guarantee that the actual annotation objects are in the detached set if the source is a single set, so we can always remove(ann) from a detached set or list.