Tim Cook wrote: > > Okay. So we now have a circular reference issue. Again, I do not > understand the value of this in any implementation.
Although ARCHETYPE - ARCHETYPE_ONTOLOGY isn't exactly a case of the Composite design pattern, nonetheless this quote from the GoF Design Patterns book (p.166) seems applicable: "Maintaining references from child components to their parent can simplify the traversal and management of a composite structure. The parent reference simplifies moving up the structure ... With parent references, it's essential to maintain the invariant that all children of a composite have as their parent the composite that in turn has them as children." > First of all; an ontology instance cannot (should not) exist outside of > an archetype instance. Therefore it is obvious which archetype it > belongs with. I don't understand how it would be obvious, Tim. You would have to search through all of the archetypes somehow in order to find the one to which the ontology belongs. > Okay, I have to object to the differential approach. > > First I like the axiom, "just because we can does not mean we should". It was more a case of, "We can't, but we have to!" Figuring out how to do it was not easy. Months of work. It wasn't done on a whim. > So, what is the technical/operational value to the differential > approach? I know that Ocean has a lot of implementation experience that > most of us do not yet have. Maybe there are good reasons? The value is that currently specialisations easily get out of step with the specialisation parent. Someone might correctly create a specialised archetype, but it's all too easy for someone to modify the parent and not update the specialisations to match. This is not a hypothetical problem: it has been happening. Another reason for differential archetypes is to make it easier for multiple people to work concurrently on the same lineage of specialised archetypes. The current flat-form archetype source is basically a crude copy-and-paste approach. It's not maintainable. - Peter
