Interface Attribute Definition Adapters

Author

Problem

Zope interfaces are object specifications. They specify the external behavior of objects that provide them. Specifications include formal information, including:

Attribute specifications
Invariants

Specifications are also provided informally as text in doc strings included within interfaces.

Attribute specifications are provided using zope.interface.Attribute objects.

There is an ad-hoc tool for verifying interfaces. It can provide crude checks for interface compliance. It is not extensible. For example, it doesn't know how to verify schema fields.

Similarly, when defining interfaces, we can use Python functions as stand-ins for method specifications. The code to handle this is hard-coded in the interface implementation.

When providing attribute definitions to interface definitions, only Python functions and objects that subclass zope.interface.Attribute can be provided.

Proposal

Use adaptation in interface definitions
Interfaces are created by calling an interface class (e.g. zope.interface.interface.InterfaceClass) with a name, a collection of base interfaces, and a dictionary of attribute specifications. The interface class will adapt each of the values in the attribute dictionary to zope.interface.interfaces.IAttribute. This means that the algorithm for defining attribute specifications will be pluggable. So, when a Python function is used in an interface definition, an adapter will be used to adapt the function to an interface. The logic for doing the conversion will no-longer be hard-coded in the interface implementation.

It will no-longer be necessary for attribute definitions to subclass zope.interface.interface.Attribute.

This has a downside. Interfaces will depend on adaptation for their definition. We will need to provide an adapter registry by default. We will also need to provide the logic for computing adapters in the adapter registry. This has the effect of bringing some of the component architecture to the interface package. (Some might view this as a positive. :)
Use adapters for interface verification
When we want to verify an object against an interface, we'll adapt the interface to IObjectVerifier, and call the verifier's verify method. The default verifier will apply this mechanism recursively for the attributes specifications for an interface.

It's worth noting that class verification (against the interfaces it implements) is iffy at best. There is no reason to require that the class provides all of the attributes that are specified in its implementation specification, or that the values of the attributes match the specifications. For example, classes may cause instance attributes to be created during initialization or a class may have attributes with the same name that it uses for its own purposes.

It's also worth noting that not all specifications can be verified. Certainly, informal specifications (words in doc strings) can't be verified formally. Even formal specifications, such as method return values may not be verifiable in practice.

Risks

This proposal ties adaptation and interface definition together rather closely. We'll need to work out how best to do this. This will require some prototyping effort. This is risky because some systems need to be able to extend the adaptation process. For example, Zope 3 requires different adapter lookup for different "sites" with an application.
A possible mitigation of this risk is to use a separate adapter registry just for interface definition.