Why must a GoObject Parent be a GoGroup?

GoDiagram (6 and previous)
1

I have a simple request/question. Why is the Parent value of GoObject implemented as a GoGroup? This prevents me from writing my own GoCollection to implement my own custom subgraph because GoLayout requires calling Parent to do layout.



Could Parent return GoObject instead? Or perhaps a new interface - IGoGroup?

2

At the beginning of this project we went through about six designs for dealing with “groups”. Some designs, including those using an IGoGroup-like interface, were rejected because of run-time inefficiency.
The implementation of GoDiagram really doesn’t have much in the way of special code to deal with GoSubGraph instances (besides the implementation of GoSubGraph itself, of course). The places where GoSubGraph matters are:

  • GoView.CreateLink and GoToolLinking.DoRelink, to make sure the link belongs to the “least common subgraph” of the link’s ports
  • GoObject.ParentNode goes up the Parent chain until it gets to either the top-level (null Parent) or until it gets to a GoSubGraph [and GoObject.ParentNode itself isn’t used at all by GoDiagram]
  • the AvoidsNodes functionality implemented by GoDocument recurses through GoSubGraphs to look for objects that meet the GoDocument.IsAvoidable predicate
    So I don’t think there is much to prevent you from writing your own class that is like GoSubGraph.