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

[Martijn Faassen]

Hey,

Marius Gedminas wrote:

> I'd like to advance the following argument that I haven't seen yet in
> this thread: discoverability.  

I was actually thinking very much about people who read the code all the 
time, but apparently I wasn't very clear. That's also why I moved away 
from a position of monkey patching to a plugin API.

[snip]
> 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.

I agree. I think therefore we should put implementations in 
zope.interface, that can defer to a plugin registered by zope.component, 
just as we have for the adapter hook. (though I think we can come up 
with a more straightforward pattern than the whole hookable stuff, which 
I think I understood once but have since forgotten :)

[snip]
> 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.)

I think the Zope community needs to be able to do all these things 
(which I've personally invested quite a bit of time on improving as 
well) *and* improve the ZCA APIs. Some people ask "why explore the solar 
system when world hunger isn't yet solved?". Lots of people have lots of 
cogent answers to that question.

We need project infrastructure, yes, but we also need a community:

* where ideas arise that when implemented affect a lot of people

* where we can discuss such ideas

* where we have people and mechanisms to reach such discussions to a 
*conclusion*

* where we have volunteers who actually implement the conclusion

If we don't have that, we don't have a functional community *either*. 
We'll always be in maintenance mode.

>>>> 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.)

Yeah, I sympathise. I believe this is an unfortunate consequence of any 
plugin system. To mitigate that issue, I think clear warning signs are 
needed in zope.interface's dummy plugin so that people who step into it 
get a clear clue something didn't get registered right.

Regards,

Martijn