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

[Chris McDonough]

Chris McDonough wrote:
> Thomas Lotze wrote:
>> Chris McDonough wrote:
>>
>>> Thomas Lotze wrote:
>>>> Because then, if you use third-party code that uses
>>>> zope.interface.Interface and other code (third-party or your own) that
>>>> uses the subclassed interfaces, you'll have to deal with both types at
>>>> the same time in your client code. You could use the new API on some
>>>> interfaces but not on others, possibly on the same line of code. How
>>>> readable or maintainable would such code be?
>>> I'm not sure, but if we had it to do all over again, this would be an
>>> obvious solution.  It would be the work of maybe two days to convert all
>>> "ZTK" packages to use a z.c.interface.Interface, and any existing package
>>> would need to be touched anyway to use .adapt and .utility.  So it bears
>>> some weight I think, even if it is eventually rejected.
>> It does certainly bear some weight as one possibility to be considered.
>> However, my point wasn't so much about converting a limited existing
>> amount of code; you're obviously right about having to touch that anyway
>> in order to use the new methods.
>>
>> My objection is this: If we go to the trouble of implementing basic
>> interfaces in zope.interface plus derived ones with component lookup
>> capabilities in zope.component and keep both around for their respective
>> reasons of existence, then it is expected that there will be code that
>> uses both types of interfaces for these very reasons (and maybe other
>> types which have other added behaviour). Such code would become a lot less
>> maintainable since you'd never know whether a given interface has a
>> particular method just because the one next to it does.
>>
>> OTOH, registering all behaviour an application needs onto the same
>> interface type doesn't create that problem. As long as you're familiar
>> with the application at large, you will know for every interface that
>> occurs in it which methods is has, how they need to be called and what
>> their semantics are.
>>
>> Also, subclassing for adding behaviour introduces the typical problems of
>> hierarchies and tight coupling. This isn't a practical problem as long as
>> we only ever talk about adaptation as the only use of interfaces, but I'm
>> trying to discuss "interfaces as a language feature" with a greater set of
>> possible use cases.
>>
> 
> Maybe a "hook" or "API extension" just isn't the right thing here.  Maybe we 
> just give up on the idea that z.component worldview doesn't belong in 
> z.interface, for the sake of implementation simplicity.
> 
> - Move the Components class from zope.component.registry to
>    zope.interface.adapter and leave behind an import alias.
> 
> - Move the "base" registry from zope.component.globalregistry
>    into zope.interface.adapter and leave behind an import alias.
> 
> - Move the getSiteManager function from zope.component._api into
>    zope.interface.adapter and leave behind an import alias.
> 
> - Move the "hookable" implementation from zope.component.hookable
>    into zope.interface.hookable and leave behind an import alias.
> 
> - Change the zope.interface.interface.InterfaceClass implementation
>    directly, adding "adapts" and "utility" methods, which would
>    use zope.interface.adapter.getSiteManager to find the registry.
> 
> z.interface would then become responsible for:
> 
> - Providing an implementation of a component registry which has
>    a z.c worldview: adapters and utilities, stolen from
>    z.c.registry.Components.
> 
> - Providing a function that returns the current component registry
>    (getSiteManager, which will continue to be hookable;
>    although maybe we should take the opportunity to rename it to
>    actually mean something).
> 
> - Providing the instance that is the "default" component registry.
> 
> All other responsibility (global API functions, a persistent registry 
> implementation, security stuff, zcml support, etc), would remain in z.component.
> 
> This would also line up conceptually with usage of "the ZCA" by BFG, which does 
> not hook getSiteManager by default, but still uses a ZCA component registry.
> 
> - C

OK, I just tried this.  It's maybe 2 days worth of effort to untangle this as 
it also effectively means:

- Moving the majority of interfaces and exceptions
   from zope.component.interfaces to zope.interface.interfaces

- Folding zope.event into zope.interface (this turns out to make sense when
   you're down the rabbit hole some of the way).

- Untangling the tests.

I thought maybe it might be a bit easier (I thought maybe I could get it done 
today) so I'm going to give up the idea of doing it "on spec" without some 
positive feedback about the idea.

- C