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
Description: Digital signature
_______________________________________________ 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 )