[Python-3000] Abilities / Interfaces

Phillip J. Eby pje at telecommunity.com
Wed Nov 22 17:04:31 CET 2006


At 08:36 AM 11/22/2006 -0500, Benji York wrote:
>It seems to me that not all interfaces coincide with something the object 
>can _do_.  Some speak to what can be done _to_ an object:
>
>class IAttributeAnnotatable(IAnnotatable):
>     """Marker indicating that annotations can be stored on an attribute.
>
>     This is a marker interface giving permission for an `IAnnotations`
>     adapter to store data in an attribute named `__annotations__`.
>
>     """

Notice that this can be defined in terms of a "get_annotation_map(ob)" 
generic function.  Classes registered for that function can simply return 
self.__annotations__ (after setting it to a dictionary, if not already 
initialized).  In fact, it seems to me that such would be the *default* 
implementation of such a function, eliminating the need to declare anything 
except for classes that need to implement annotation storage 
differently.  Or am I misunderstanding the intended use?


>Some give describe how the object will _act_: Persistent.

Which indicates what outside operations can be performed on the object, 
such as "load", "save", etc.


>   Some are application-level statements about how what is allowed to be 
> _done_with_ the object: ISharable (the user can "share" this object with 
> other users in various ways; read, write, etc.).

Aren't these also *operations* being performed?


>These (especially the marker interfaces) don't seem to be statements about 
>what the objects can do (abilities),

"Ability" doesn't imply that the object itself has to do the thing.


>  but about other characteristics,
>therefore a more general name like "interface" seems appropriate.

Actually "ability" is more general than "interface", because interface 
implies two things talking to one another.  Some Zope uses of "interfaces" 
don't include any actual "interfacing" at all, so to me your examples 
actually support calling them "abilities" rather than "interfaces".



More information about the Python-3000 mailing list