We should not allow adding instance as descendant #563
Comments
kecso
added a commit
that referenced
this issue
Sep 15, 2015
now the gme concepts checks for every level of containment to avoid crossings in the containment hierarchy and the inheritance chain it is still possible to create loops / crossings in the inheritance chain and containment hierarchy as not all elements can be checked at the time of modification
kecso
added a commit
that referenced
this issue
Sep 17, 2015
… collision if they found such node, they remove it on-demand
kecso
added a commit
that referenced
this issue
Sep 17, 2015
kecso
added a commit
that referenced
this issue
Sep 18, 2015
As some generic UI pieces depend on the fact, that there is only the FCO (and the ROOT) which doesn't have a base, we prohibit its copy. This restriction however exsits only on the UI as in theory the core layer can handle multiple objects without base. We also checks for situations which cause unloadable nodes. More precisely when a node contains its base. As not all situation can be avoided beforehand we remove such nodes during their load. This issue is the opposite of #563 A possible scenario: 1. create typeA and typeB 2. create an instance of typeA (instA) 3. move typeB inside instA 4. move typeA inside typeB (at this point we are unable to prohibit the move as we not necessarily know about instA being a descendant of typeA) -> instA become unloadable
kecso
added a commit
that referenced
this issue
Sep 18, 2015
As some generic UI pieces depend on the fact, that there is only the FCO (and the ROOT) which doesn't have a base, we prohibit its copy. This restriction however exsits only on the UI as in theory the core layer can handle multiple objects without base. We also checks for situations which cause unloadable nodes. More precisely when a node contains its base. As not all situation can be avoided beforehand we remove such nodes during their load. This issue is the opposite of #563 A possible scenario: 1. create typeA and typeB 2. create an instance of typeA (instA) 3. move typeA inside typeB 4. move typeB inside instA (at this point we are unable to prohibit the move as we not necessarily know about typeA and that it is the base of instA) -> instA become unloadable
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently we only forbid to add an instance to the node as a direct child (which means that parent !== base should stand for all nodes), but we not check for more distant relations.
The containment hierarchy and the inheritance chain of a node should never cross each other.
The text was updated successfully, but these errors were encountered: