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.



> 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 Fulton
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope )

Reply via email to