Wolfgang Schnerring wrote:
* Martijn Faassen <faassen@startifact.com> [2009-12-17 17:48]:
* Thomas Lotze <tl@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.)
I'm saying that because I don't recall people arguing against this before. Since the __call__ logic is only about adapter lookup, does this mean that your argument is expanded against this as well or does it fall under the notion of looking up anything by interface? I think from the rest of your mail that you mean the latter. At least it's a strict subset of an expanded notion of "lookup". [snip]
By putting method stubs into zope.interface which are exclusively about concepts of zope.component we would be
I would say that to be consistent in that position, you would need to argue not just against method stubs but against the presence of these methods at all, no matter where they come from. The rest is just an implementation detail. Reasoning from your position that zope.interface shouldn't have notions of adapter and utility lookup, it hardly matters what package implements these methods. To the user of Interface it will look the same, except that zope.component monkey-patching things in would be harder to understand and debug. To be consistent we have the following options: * only provide a general notion of "looking up something by interface" in zope.interface. This general notion unfortunately clearly doesn't have support from a large number of people so sadly I had to let that go. * not change anything at all. Looking up these things remains the task of zope.component and we better use zope.component APIs. Monkey-patching methods in from another package to me looks like it doesn't improve the conceptual story at all. Conceptually Interface ends up as messed up as before and it becomes more difficult to understand what's going on for the code reader or debugger.
which might or might not take additional parameters such as a name to look them up ... for me emphatically do *not* belong to what "interfaces" are about.
I think you can see a name as another context in a multi-adaptation, where this context is special in that: * it needs to be human-readable text * it cannot extend another name, unlike interfaces, which can extend each other It's just a handy shortcut. :)
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.
I don't think the dependency refactoring argument holds. We were untangling physical dependencies. This wouldn't change physical dependencies one bit: zope.component would still depend on zope.interface. There are likely tons of places where package A depends on package B and also configures package B, changing its behavior. This would be no different: zope.component depends on zope.interface and plugs into it as well to configure some of its behavior. That's what it does today with the adapter hook. Putting notions of conceptual purity aside, I was arguing for a pragmatic solution that results in code that is as unsurprising as possible. I don't think .adapt and .utility are perfect, and I would have gone for another solution myself (a more generalized lookup method), but they seem to have consensus support. I don't think they do much in the way of active harm by being there in zope.interface. They help readability of the code that uses them. Moreover, this pragmatic solution would make code that looks up multi adapters and utilities more convenient to write. So, zope.interface needs to gain these methods, and open up a plugin point so that these methods can be fully implemented by another package. I think this can be constructed so that the only new notions to zope.interface are: * multi-adaptation, an extension of adaptation * look up by name, a conceptual extension of multi-adaptation :) * utility lookup Too many for my tastes when there's such an elegant general lookup method available, but I can't convince enough people of that. If we are going to make Interface support these methods for pragmatic considerations, we should just face it and implement them on Interface (delegating to a plugin). Anything else just helps to obfuscate what is going on. Regards, Martijn