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

[Chris McDonough]

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