[Zope-dev] A summary of "Interfaces vs ZCA concepts"

[Marius Gedminas]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20091217/e67d7d00/attachment-0001.bin