[Zope-dev] Re: [Geeks] Interface Meta Data proposal

[Jeffrey P Shell]

On 11/28/00 4:05 PM, "Michel Pelletier" <michel@digicool.com> wrote:

> 
> I've added a sub-proposal to the Interface proposal for describing
> additional meta-data with Interface objects:
> 
> http://www.zope.org/Wikis/Interfaces/ExtesableMetaData
> 
> Please comment about this interesting possibility.
> 
> -Michel
> 

Without these things being supported more in the core language, it seems
quite awkward.  Being able to do the followng is nice:

class ILockToken(Interface.Base):
    def frame(self, width, height):
        "a frame"

class LockToken:
    __implements__ = ILocktoken,
    ...

The following would (will?) be better:

interface ILockToken:
    def frame(...):

class LockToken implements(ILockToken):
    ...

But I'm not sure how one would go about setting your meta-data in a way that
is at all natural to Python.  I think that exceptions that a method
must\should raise *should* be part of a signature\contract.  This is one of
the really cool things about Java.  If you use a method, 'readFile' that
says it raises IOError, you *HAVE* to catch that exception (I believe in
order to compile).  But it looks like what you're really wanting is to use
interfaces for documentation purposes, not for contract purposes.  Not for
interfaces at this level of the language.

I'm guessing along your proposal, to state that a method raises ValueError
or Attribute I'd have to do the following?:

class ILockToken(Interface.Base):
    def frame(self, width, height):
        "a frame"
    frame.setMetaData('exceptions', (ValueError, AttributeError))

...

Meta Data is a deadly term.  Be careful with it.
Anyways, I doubt we want to invent our own IDL (no!) or reinvent Eiffel
(specifying pre and post conditions are only truely useful if they're
enforced, and without this enforcement in the core language I imagine that
could be expensive. They're a good thing for large systems, but Python
doesn't support them automatically), so it seems that this information seems
to be best put in the documentation (since doc strings in an Interface don't
also mean "Publish Me!", they can be used to document!).

Interfaces are contracts and pretty darn good ways of specifying parts of
the system, but don't confuse them with headers in C\C++\Objective C.
'IObjectManager' is a critical interface for Zope (so instead of having
attributes like 'isPrincpiaFolderish', we can ask
'IObjectManager.implementedBy(fooObject)'.  Folder, on the other hand, is an
important class in Zope, but is primarily an amalgam of classes implementing
important Interfaces (ICopyable, IPropertyManager).  It's unlikely that
we'll really have a need for a Folder Interface, because what's important
about Folder's is that they implement ObjectManager behaviors and
CopySupport behaviors.

To bring Java back into play here for a moment, a simple example is the
interface 'Cloneable'.  By implementing 'Cloneable', well then..  when it's
time to clone, you can be cloned.  If you don't say you implement
'Cloneable', an exception gets raised (even if you implement the proper
method).  This is similar to how we sniff things today, but we just do
things like 'if hasattr(obj, "cb_isCopyable") and obj.cb_isCopyable()):'

I get the feeling sometimes that what you want with interfaces is actually a
bit closer to what Objective C does with the word Interface.  And that is
that in Foo.h, you have the interface for class Foo:

@interface Foo {
...

And in Foo.m, you have the implementation:

@implementation Foo {
...

These interfaces are header files, and they're damn nice to use for
documentation since the specification of the class is separate from the
implementation.  But they don't imply contracts in the way that Java's use
of the word Interface does.  (Some implementations of Objective C call those
things Protocols).

Both needs are valid, but I think we'll benefit most from the first
(contracts).  In order to make those work, we probably shouldn't make them
too foreign to specify, or the incentives to write them go way down (as is
evidenced by the amount of doc strings that go """ """ or "XXX: Fill in
later", getting developers to fill in too much 'meta data' is hard).

But if we can get some of the information in your proposal more integrated
with the language, I think it would be beneficial.

Jeffrey P Shell, jeffrey@Digicool.com
http://www.digicool.com/ | http://www.zope.org