[Zope3-dev] "Sub interface"

[Terry Hancock]

I have researched the Wikis and ML archives regarding 
interface implementations in Zope, and have not found
anywhere the concept of a "sub-interface" which I 
implemented because I found it indispensable in my
product design.

A sub-interface inherits from Interface.Attribute, but
has an extra property specifying the expected interface
of the attribute.

This is very much inline with the idea of having method
attributes that specify the expected calling signature,
as indeed, Interface.Method lets you do.

This is much better than specifying the Attribute's type, 
for the same reason that interfaces are better than pure 
inheritance.  And also because it's much more flexible.

Needless to say, this works recursively -- a subinterface
may itself have subinterfaces specified.

In addition to providing the recursive definitions, of 
course, my module provides a verification function that 
chases down the subinterfaces and checks them, thus doing a 
more thorough interface check than is included in 
Interface.verify.  It's actually this part that breaks due 
to API changes.

I can provide detailed use-cases if they aren't obvious to 
you, but here's just a suggestion:

Consider, for example, the case of an attribute of a 
document called "license" which should implement a 
particular licensing interface, that, for example, explains 
what can legally be done with the document, and may 
actually control compliance.  The document will likely 
point to a "license object" which specifically implements 
say "GPL" or "MIT" or "DSL" licensing rules within a CMS.

You don't want this document to inherit directly from the 
appropriate license -- you want it to be represented as an 
attribute. You might even have many objects point to the 
same license object, for example.

Anyway, the reason this came up is because I wrote it as an 
extension to the "Interface" module provided in Zope 2.5.1. 
That has changed extensively, and my code is now completely 
broken in Zope 2.7 (it's beyond a few name fixes -- I need 
to just rewrite the thing.  Fortunately it's less than 100 
loc or so).

So I want to answer the strategic question of how to 
proceed with fixing this problem.  Should I:

0) Lift the 2.5 code and insert it into my product source 
tree?  (I guess not -- tried it already, this fails with a 
traceback, apparently having to do with the fact that Zope 
can't coexist with my interfaces on the __implements__ 
attribute.  A ML thread suggests the same problem occurs 
when mixing Zope 2 and 3 interfaces).

1)  Port my code to be consistent with 2.7?  (In which 
case, what exactly changed and why?  I see new interface 
declarations for interfaces themselves, which is cool, and 
some of the functions and methods changed names. I also am 
disturbed to find the term "superinterface" which I don't 
understand -- and there are other intimations of new 
concepts here which I can't find any description of).

2) Port my code to be consistent with X3?  I'd like to 
leapfrog to the newest implementation.  But this will have 
to be included in my own sources to work with Zope 2.7, and 
I'll have the same problem as with using the 2.5.1 
implementation, won't I?

3) Actually write this feature into the X3 "interface" 
module as a contribution to the Zope sources.  Seems like 
it would be useful to others, and it should be just as 
easy. For my immediate use, though, it looks like I have 
the same problem as 0 & 2 for use with 2.7.

4) Contribute it also to the Zope 2.7 "Interface" module,
which I guess would mean having it included in some Zope 
2.x release.

A cursory look at the Zope 2.7 Interface and Zope X3 
interface modules suggests that they are pretty similar, 
but not identical.  How much change has gone on? Especially 
at the conceptual level where it will mean more than just 
subbing a few names?

Anyway, I'm looking for comments or advice on how to pursue 
this.

Thanks, 
Terry

--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com