[Zope-dev] [Checkins] SVN: zope.intid/trunk/ - Remove a dependency on ``zope.container.contained.Contained``
faassen at startifact.com
Fri May 15 07:48:41 EDT 2009
Chris McDonough wrote:
> On 5/15/09 2:46 AM, Michael Howitz wrote:
>> Am 15.05.2009 um 05:32 schrieb Chris McDonough:
>>> Log message for revision 99961:
>>> - Remove a dependency on ``zope.container.contained.Contained``
>>> (this is a dumb base class that defines __parent__ and __name__
>>> as None and declares that the class implements IContained).
>> What's the reason behind this refactoring?
>> Instead of zope.container.contained.Contained the IntIds class now
>> depends on zope.container.interface.IContained plus it redefines the
>> things which are already defined in zope.container.contained.Contained.
>> I do not see why this is better than using the base class.
> 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. ;-)
Agreed with Chris; IContained interface is very minor and it's easy
enough to reimplement. If that helps us reduce dependencies I say let's
not worry about this step.
We might consider moving IContained to zope.location - it just
subclasses from ILocation after all and doesn't add anything besides
being a marker interface. zope.intid already depends on zope.location.
The Contained implementation could even move to zope.location, actually.
Hm, I wonder what code actually *depends* on IContained (instead
Thanks Michael for watching the checkins carefully. Do keep bringing up
whatever issue you see here and we'll discuss it. Even if the checkin
stands, it can lead to useful discussions nonetheless.
More information about the Zope-Dev