[Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
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
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