[Zope3-dev] Proposed terminology change: distinguish between "implements" and "provides"

Phillip J. Eby pje@telecommunity.com
Fri, 07 Mar 2003 13:48:28 -0500


After studying the proposal further, it seems to me that a big source of 
confusion in talking about interfaces is the overloading of the term 
"implements" to describe two things:

1) the interfaces that a class provides for its instances
2) the interfaces that a specific object supports

I would like to suggest that we use two different words for these things, 
both in discussion and in the terminology of the API.

Because in other languages "implements" already means #1 above, I think we 
should stick with "implements" for that concept, but we should have a 
different word for idea #2.  I suggest "provides", although I think an 
argument could be made for "supports" as well.

In short, we would say that "a class implements interfaces that its 
instances provide", and that "objects can declare that they provide 
additional interfaces beyond what their class implements".  These 
statements are much less awkward than the phrasings required by the current 
terminology.

Based on this, I would like to propose the following changes to the 
currently proposed IImplements interface:

* implements(*interfaces) - leave as is

* classImplements(class_) - rename to 'implementedBy(class_)'

* objectImplements(ob) - rename to 'directlyProvidedBy(ob)'

* moduleImplements(*interfaces) - rename to 'moduleProvides(*interfaces)'

* interfaces(ob) - rename to 'providedBy(ob)'

* NEW: add 'classProvides(*interfaces)' - equivalent to 
'__class_implements__ = interfaces'


These changes would ensure that 'implements' always means what a class' 
instances provide, and 'provides' always is what an object itself 
supports.  Thus, for example, we say 'moduleProvides' because in this 
terminology, a module can't "implement" anything; only classes can 
"implement", and then only for their instances.

Revised examples:

         from zope.interface import implements, implementedBy, classProvides,

         class Foo:
             implements(IFoo)

         class Bar:
             implements(implementedBy(Foo), IBar, IBaz)

         class ServiceSubscriberEventChannel(SubscriptionTracker, 
EventChannel):
             """An event channel that wants to subscribe to the nearest
             event service when bound, and unsubscribe when unbound.
             """
             implements(
                 implementedBy(EventChannel),
                 implementedBy(SubscriptionTracker),
                 IBindingAware
             )


         moduleProvides(IFoo)

         class Blee:
             classProvides(IFoo, IBar)


         obj = traverse('/foo/bar/baz')
         directlyProvidedBy(obj).add(IFoo, IBar)


         print implementedBy(Foo)        # what instances of Foo provide
         print providedBy(Foo)           # what Foo provides, including 
implemented by its class
         print directlyProvidedBy(Foo)   # what Foo provides beyond what 
its class implements


I still have some concerns about the semantics of inheriting interface 
specs, and especially the semantics of modifying shared specs.   I want to 
review the current proposal some more and give it a bit of thought before 
commenting, however.  Hopefully I will be able to do that later today.