Wolfgang Schnerring wrote:
> * Martijn Faassen <faas...@startifact.com> [2009-12-17 17:48]:
>> * Thomas Lotze <t...@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
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".
> 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
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
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
> 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
* 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
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -