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

Chris McDonough chrism at plope.com
Fri May 15 12:20:45 EDT 2009


On 5/15/09 6:27 AM, 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.
>
> 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.  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.

This particular changes is a nobrainer.  It replaces a base class that defines 
__parent__ and __name__ as None.  It just can't be more understandable to have 
IntIds subclass from Contained for a new developer.  When it subclasses from 
Contained, they have go look over there to see if it does anything interesting 
and it just doesn't.

Breaking small import dependencies like this one is useful even if you don't 
manage to break any full package dependencies, if only to get the "little stuff" 
out of the way to start thinking about whether it makes sense to do anything 
larger.  I *didn't* make any other changes because I don't know what the right 
thing is wrt interfaces and such, and I don't want to make things even worse.

- C


More information about the Zope-Dev mailing list