On Thu, Dec 17, 2009 at 05:48:04PM +0100, Martijn Faassen wrote:
Thomas Lotze wrote:
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.
I don't understand you: why do you say they lie about their method signature? They should have the same signature and have a well-defined behavior if zope.component is not installed: there is nothing registered at all. zope.interface provides a plugin point that allows one to plug lookup behavior into it.
In that sense, these stubs would be worse than zope.interface not documenting the methods at all.
I strongly disagree. We want to define a bunch of methods on Interface that we want everybody to have access to. We can't then turn around and say we really actually don't want to implement those methods on Interface.
That Interface *delegates* the implementation to something else is fine, but the methods are conceptually on Interface, and delegation is normally implemented by just calling the code we delegate to.
I'd like to advance the following argument that I haven't seen yet in this thread: discoverability. Specifically, letting the developer figure out what's happening. When I see code like this: formatter = IHTMLFormatter(widget).to_html() I can look up the definition of IHTMLFormatter, see that it's a "class" inheriting from Interface, look up zope.interface.Interface, see that it's an InterfaceClass instance, look up InterfaceClass.__call__ to see what it does -- checks for widget.__conform__, checks if widget provides IHTMLFormatter directly, loops through adapter_hooks. Then I can grep for adapter_hooks in my buildout omelette tree and find that zope.component hooks into it. And so on. If there's only monkey-patching going on, I'd get stuck in step 4: InterfaceClass has no __call__. Where does it come from? Monkey-patching is sufficiently frowned-upon in the Python world that it wouldn't occur for me to recursively grep "InterfaceClass.__call__ ="; I'd assume I missed something and run in circles. The main point of my email completed, I still cannot force myself to desist from further comments.
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.
In that case, I want the real contract to be in zope.interface. That's where the methods are, after all. We need to talk about the concept of an adapter and a utility briefly in zope.interface and defer to zope.component as the most common implementation. We already have this kind of behavior going on anyway with __call__() (even though not documented!).
It'd be simpler if utilities didn't exist as a concept in zope.interface, but y'all have decided that's too ambitious. (Personally I kinda think redesigning zope.component/zope.interface APIs is too ambitious; the Zope community would be better served by having a website with up-to-date documentation of everything, launchpad bug trackers for every package in the ZTK and KGS, stable and regular ZTK and KGS releases, etc. But I know that I have no right to tell anyone what they should work on instead of their chosen pet project.)
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.
So if no registry is available (zope.component not installed), you can still call it and it'll just behave as if the registry is empty? That's good..
(Unless it trips people up leading them to assume they made a mistake in their adapter/utility registrations, when they instead forgot to register the hook. But that's unlikely, as I've already said elsewhere.) Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development