Martijn Faassen wrote: > Here's a summary of what has been going on in this thread with some > attempts at conclusions that have support of the consensus so that Thomas > can proceed
Thank you, half an hour later and I'd have written the summary ;o) > * We want to implement .adapter(), .utility() and .__call__() in > zope.component as much as possible. The method's name is `adapt`, JFTR. > * we want a similar mechanism for each of them to plug in. Agreed, even though (AFAICT) we haven't been talking about moving the implementation of __call__ to zope.component so far. > * It'd be nice if __call__ came back with a LookupError instead of a > TypeError, but how to get from A to B without breakage? It's not possible without breakage. I'd say changing the error is worth a 4.0 release, but we might want to postpone this change and see whether there's anything else we want to change about zope.interface in a backwards-incompatible way, and if so, put that in the 4.0 release as well. I guess we don't want too many backwards-incompatible releases of such a central package. One thing I start questioning is an adapter registry being implemented by zope.interface. Moving it to zope.component seems to me to be related to keeping the implementations of the new method within zope.component. > * there was some discussion about general plugin points on Interface. > Those have a complexity cost compared to simply poking the methods into > the class. As for poking the methods into the class, see the new tlotze-patching-interfaces branches of zope.interface and zope.component for the minimum change this would take IMO. The change to zope.interface is really just about documentation. > * the methods can be on zope.interface even if zope.component isn't > installed. They will behave as if the component registry is empty. This isn't covered by the consensus you mentioned above as far as I'm concerned. > Their behavior should be: > > IFoo.adapt(context) raises LookupError, unless the context provides IFoo, > in which case it returns context. > > IFoo.adapt(context, default=default) returns default unless context > provides IFoo, in which case it returns context. > > IFoo.utility() raises LookupError. > > IFoo.utility(default=default) returns default I think looking at that API explains why we have trouble with having stub methods defined by zope.interface: these methods contain enough information about component concepts to blur the distinction between zope.interface and zope.component, but they still lie about the actual method signature. In that sense, these stubs would be worse than zope.interface not documenting the methods at all. In my and Wolfgang's opinion, we can either have zope.interface implement methods with the real contract, which would mean defining the full concepts of the ZCA within zope.interface (if not their implementation), or not even have method stubs in zope.interface and leave the whole business of defining specialised uses of interfaces to other packages such as zope.component. > What's the behavior of __call__ now if zope.component isn't around? Similar to what you've just described of your `adapt` method, up to the name of the `default` parameter and the exception raised. > * Tres brought up that we can come up with a clean plugin interface > instead, and now I'm tempted to go for that instead of monkey-ing around. [...] I'd have to think about that some more, but while reading it the first time, it feels quite wrong to me. > I realize that the proposal for a plugin API gives zope.interface some > knowledge about adaption and utility lookups, which is what Thomas and > Wolfgang had trouble with. But after all that's what we're doing anyway by > putting those methods on the API, one way or another. No: the zope.interface package doesn't have any knowledge about the particulars of any of the uses of interfaces. One might claim that interfaces do after they've been patched by other code, but then, that's after some application has made its choice about plugin certain packages together. It's not baked into zope.interface, and that's what we're trying so hard to achieve. > [Philosophically from my own perspective I think we'd have much less > conceptual difficulty with this if we just made __call__ do all lookups, > as that hides the whole set of concepts of utility versus adapter a bit, > but we can't get consensus for that unfortunately. But I'm biding my > time..] Implementing __call__ within zope.interface in that way would get the package rid of the method names `adapt` and `utility`, but the technical problem with the method signatures and the more philosophical one about whether zope.interface should really make adaptation stand out as a use of interfaces remains. Which brings me back to the question I asked earlier, and which nobody has replied to so far: Do we want to make zope.interface completely unaware of any particular uses of interfaces, or do we want to treat component lookup and in particular the ZCA's way of looking up components as a special case? -- Thomas _______________________________________________ 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 )