* Martijn Faassen <faas...@startifact.com> [2009-12-17 17:48]: > * Thomas Lotze <t...@gocept.com>: > > zope.interface [should be] completely unaware of any particular uses > > of interfaces > > Why is it a problem that the zope.interface package gains knowledge > about adaptation (which it always had, anyway) and utility lookup?
This is the key issue, I think. (And I'd like to ask you not to argue "it has always been that way", since what we're trying to do here precisely is to improve the status quo.) The question is, which concepts belong into zope.interface and which don't? One might also phrase that as, what is the responsibility and purpose of zope.interface (drawing upon the software engineering terms of cohesion and coupling). My opinion is that > [__call__ introduces] the following notion into zope.interface: > "please look up an object that provides this interface, somehow. (with > zero or more context objects)" might well belong into zope.interface, but that anything of these: > adapters, utilities, null-adapters or contextual utilities absolutely do not. I think there is a clear distinction between what "interfaces" are about and what "component architecture" is about, and I think it is worthwile to maintain and clarify that distinction. For me, a notion of "looking up something that provides an interface" belongs to what "interfaces" are about. But notions of "utilities" which might or might not be singletons, of "adapters" which might or might not take additional parameters such as a name to look them up, or notions of a "context" or a "registry" (which for me comes up immediately when thinking about "global" vs. "local" utilities) that influences the lookup, for me emphatically do *not* belong to what "interfaces" are about. By putting method stubs into zope.interface which are exclusively about concepts of zope.component we would be a) On a conceptual level: blurring the distinction between the two packages and concepts, which I think is a Bad Thing(tm) b) On a more practical level: coupling zope.interface to zope.component. Given all the recent efforts of untangling the dependency structure between our packages, I think doing that would be a step in the exact opposite direction. Wolfgang _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
