On Tue, Dec 7, 2010 at 1:38 PM, Chris McDonough <chr...@plope.com> wrote: > I'm trying to decide whether to repurpose the conflict detection in > zope.configuration for non-XML configuration.
Cool. ... > Unfortunately, the documentation in the code tends to explains the > mechanics of conflict resolution, but not the intent. I'll take a guess > though: > > - the "rootmost" directive that participates in a conflict is meant to > "win". > > - if there is more than one "rootmost" directive that participates in a > conflict, the conflict cannot be resolved. > > Does my summary sound about right? Yes, but ... > Does anyone have any insight as to > why this particular conflict resolution strategy was chosen? I'm really > just trying to understand the intent. The intent was to provide a way of overriding configuration in a way that was unambiguous and understandable. (Of course, it fails in the case of subscribers, but I think that's beside your point. :) Let's take this up a level, to user goals. A user wants to reuse a high-level component (aka package aka "project" in distutils jargon aka "product" in distutils jargon). They want to customize the high-level component without hacking its code. *That* is really the intent. Jim -- Jim Fulton _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )