[Zope3-dev] Re: zope.annotation dependency to zope.app.container.contained
On 2007-08-09 20:51:26 +0200, Philipp von Weitershausen [EMAIL PROTECTED] said: Roman Joost wrote: we're doing some dependency checking at gocept and I discovered that zope.annotation depends on zope.app.container in its factory. What shall we do with this dependency to zope.app.container? Moving this factory to zope.app is probably not the best solution. To be clear, zope.annotation doesn't depend on zope.app, it depends on zope.app.container which is its own package and egg (and in fact, zope.annotation's dependencies are refreshingly few). The real problem is that zope.app.container depends on a whole bunch of other things. The question is why. Okay, actually I think that zope.annotation uses IContained. This is just wrong but also results in an underspecification of IContained: class IContained(ILocation): Objects contained in containers. When you read it very carefully you figure that it actually says is that object.__parent__[object.__name__] would result in the object again. IContained states how you can get the object from the __parent__. ILocation doesn't do that. For the annotation factory using zope.location and ILocatable would be sufficient. So we could get rid of the zope.app.container dependency. We should be a bit more specific about the IContained interface. Does it make any sense to have an IContained object without __name__. I think not. Chaning that would make __name__ a required attribute on IContained. Comments? -- Christian Zagrodnick gocept gmbh co. kg · forsterstrasse 29 · 06112 halle/saale www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: zope.annotation dependency to zope.app.container.contained
On Wednesday 15 August 2007 07:43, Christian Zagrodnick wrote: For the annotation factory using zope.location and ILocatable would be sufficient. So we could get rid of the zope.app.container dependency. +1 We should be a bit more specific about the IContained interface. Does it make any sense to have an IContained object without __name__. I think not. Chaning that would make __name__ a required attribute on IContained. +1 Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.annotation dependency to zope.app.container.contained
Roman Joost wrote: we're doing some dependency checking at gocept and I discovered that zope.annotation depends on zope.app.container in its factory. What shall we do with this dependency to zope.app.container? Moving this factory to zope.app is probably not the best solution. To be clear, zope.annotation doesn't depend on zope.app, it depends on zope.app.container which is its own package and egg (and in fact, zope.annotation's dependencies are refreshingly few). The real problem is that zope.app.container depends on a whole bunch of other things. The question is why. Michael Howitz's email about ISite demonstrates a recurring problem: There are several packages that do two things. One one hand they define concepts (IContained, ISite, etc.) and a little bit of machinery (contained(), getSite(), etc.) to deal with these concepts. On the other hand they also provide full-fledged implementations. Those implementations are the ones that end up introducing lots of dependencies (because they involve security, events, persistency, etc. etc.) Perhaps it makes sense to factor the *concepts* and the light-weight helpers (contained(), getSite(), etc.) out to separate packages, e.g.: * zope.container * zope.componentsite * ... There wouldn't even be a BBB problem, we could just leave import the interfaces and helpers from the new location and leave them there forever. That way, packages won't break if they still depend on zope.app.container and zope.app.component. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com