[Interface-dev] Some thoughts on attribute specifications in interfaces

[Jim Fulton]

Lately, I've been working on a proposal for defining method parameters
in interfaces:

   http://dev.zope.org/Zope3/MethodSpecification

This has gotten me thinking about fields (from zope.schema), which
model the attributes of objects that provide interfaces.  After
thinking about this a bit, I realized that I've been thinking about
attribute specifications (including methods and fields) incorrectly.
I had thought of attribute specifications as specifications for
attribute values, but they are really more than that.  Attribute
specifications are really specifications for a relationship between an
object that provides an interface and a specification for an object
that provides an attribute value:

                       _______________
                       | attribute x |
                       ---------------
                             |
      _________              |            _______________________
      | iface |---------------------------| Value Specification |
      ---------                           -----------------------

When thinking about attribute specifications (e.g. schema fields)
we should separate the modeling of the relationship from the
specification of the value.

For example, using zope.schema, we can model an attribute:

    class IFoo(Interface):

       size = Int(description="The number of doo dads in a foo",
                  required=False,
                  min=0,
                  )

This says that objects that provide IFoo have size attributes.
The size attributes are positive integers. An alternative way to
express this might be:

    class IFoo(Interface):

       size = Attribute(description="The number of doo dads in a foo",
                        required=False,
                        type=Int(min=0),
                        )

Here, we use an Int specification. Unlike the Int field in the
previous example, the Int specification only deals with the value.
One could reuse the Int specification in method parameter definitions,
or accessor-function definitions, or even key definitions.

Note that a variety of specification styles could be supported, such as:

- types (int)

- Interfaces (IInt, which might allow longs)

- Unions (Union(IInt, NoneType))

- Sets (Set([1,2,3,4,5,6,7,8,9,10))

Note that thinking about attributes as relationships between objects
(or specifications of objects) sheds some light on the schema binding
issue we've been wrestling with:

   http://dev.zope.org/Zope3/NoMoreSchemaBinding

It now seems natural to me that, when applying an attribute definition
to an attribute manipulation task, such as display, input, or
validation, that we would take the object the attribute is on into
account.

Consider the problem of displaying an object attribute on a form.
Currently, we "bind" the field to the object and then get an adapter
(view) on the bound field. I think a better way would be to get a
three-object adapter (view) on the field value specification, the
attribute specification, and the object that provides the schema.
This allows us to dispatch to an adapter based on the value
specification, which is generally most important for selecting display
components, the attribute specification, and the object type.

For validation, we'd use subscription adapters on the value
specifications, the field types and the object type.

These ideas are similar to those proposed in:
http://dev.zope.org/Zope3/NoMoreSchemaBinding
except that 3-object, rather than 2-object adapters are used.

Note that we could implement this in a way that would retain backward
compatibilities with existing schemas.

Thoughts?

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org