[Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``

Martijn Faassen faassen at startifact.com
Fri May 15 08:15:18 EDT 2009

Fred Drake wrote:
> On Fri, May 15, 2009 at 2:57 AM, Chris McDonough <chrism at plope.com> wrote:
>> It's a partial step towards getting rid of a dependency that zope.intid has on
>> zope.container.  I'm thinking that maybe that IContained interface belongs in
>> some other package (e.g. maybe zope.contained).  That Container base class is..
>> uh.. not complicated, so even if we never do get rid of the zope.container
>> dependency completely, it really doesn't harm anything to not use Contained.
>> Unless you have some nostalgia for it. ;-)
> At the rate we're going, every class and every interface is going to
> be in a separate package.

I don't think we have many examples of this. We have zope.browser as a 
repository of some interfaces. The other such package off the top of my 
head is zope.broken, and that one really isn't pulling its weight so I 
hope the IBroken interface can eventually move elsewhere. (someone, 
analysis please? perhaps we need a package to hold content-specific 
interfaces, equivalent to zope.browser. IBroken and IContained might 
move there.. but see below)

There hasn't been a lot of splitting off of classes into new packages as 
far as I know. We moved a lot from zope.app into zope. to leave the ZMI 
behind, but I don't think that's been a bad exercise at all.

> Keeping the dependency graph clean is great, and there's plenty to do
> there. But there's also something to be said about being able to keep
> a substantial portion of it in your head. 

Those two goals are not mutually exclusive and in fact mutually 
supportive. It's not like it was easy to keep a portion in your head 
before this work started anyway - it was a horrible, horrible, horrible 


I'd argue it's easier now that we can actually *read* the graphs. :)

> The cleanliness of the
> graph isn't so important if most users still can't understand just
> because there are so many pieces that they wouldn't normally use
> directly.

I appreciate that point. We shouldn't be generating a lot of small 
pieces if we can help it. That's why it is important as a first impulse 
to look at existing packages to move an interface into. Sometimes a 
dependency inversion is the right way forward.

I think in the case of IContained it wouldn't hurt us much moving this 
interface to zope.location, as IContained is just a marker. It's not as 
clean as we'd like, but the dependency graph will be much cleaner if we 
do and it's not horrible either.

We want both less packages and cleaner dependencies. I don't think we're 
moving in the wrong direction at present though, so I don't think it's 
the time to pull on the package-generation breaks just yet.



More information about the Zope-Dev mailing list