Each project can have multiple "parents" (projects for which they are sub-goals) and "children" (their own sub-goals).
How do dependencies fit in here?
Implementation Options
Implicit links
Links are modeled as inst vars e.g. parent/child
Items don't know their container - In MyPeople, organizations don't know their address book, but all organizations are held by that container. As a result, there is API to add a parent (which assumes it's already held by the container), but no API to add a child, because there's no way to walk up the tree to the container to add the child there as well. This used to also be the case for LivingLibrary's AuthoredWorks, but it seemed too confusing so I broke down and added #addressBook state for contact objects.
Items know their container - In Virtual-Stash however, Accounts know their container, so adding a child adds the child to the container, and specifying a parent assumes it's already in the container.
Roots vs. Flat List
One question in the implicit linked model is: are all projects in a flat collection in the list, or the roots only with iterators to walk the tree? We will reimplement project list to contain a flat list. See #11
Explicit links
Links are first class objects held by the same container as the items they link. For some reason, this seems the most natural for a mind-like container. It seems to be calling out in that context. I guess the items would have to know their container and ask the container for the links (or cache them themselves). But not clear here. Although in one respect, I guess caching/indexing/optimizing is really what's at play here - who keeps track of what. And maybe it only matters when one tries to optimize.
Thinking it through further, it seems that there can be multiple parents and multiple children. This is seeming less like a tree and have a feeling explicit links might work well.
Each project can have multiple "parents" (projects for which they are sub-goals) and "children" (their own sub-goals).
How do dependencies fit in here?
Implementation Options
Implicit links
Links are modeled as inst vars e.g. parent/child
#addressBookstate for contact objects.Roots vs. Flat List
One question in the implicit linked model is: are all projects in a flat collection in the list, or the roots only with iterators to walk the tree? We will reimplement project list to contain a flat list. See #11
Explicit links
Links are first class objects held by the same container as the items they link. For some reason, this seems the most natural for a mind-like container. It seems to be calling out in that context. I guess the items would have to know their container and ask the container for the links (or cache them themselves). But not clear here. Although in one respect, I guess caching/indexing/optimizing is really what's at play here - who keeps track of what. And maybe it only matters when one tries to optimize.
Thinking it through further, it seems that there can be multiple parents and multiple children. This is seeming less like a tree and have a feeling explicit links might work well.