[Zope-dev] RFC: Python/Zope Interfaces - More ZCatalog ;-)

[Chris Withers]

Jim Fulton wrote:

> > It is a very good thing to have the specification very near
> > to the implementation -- as a permanent guide to the
> > implementor.
> 
> Firtunately, modern displays allow multiple side-by-side
> windows. ;)

G400, two displays :-)

> > It is even better, when big parts of the
> > specification becomes part of the executable code
> > (as is the case for Eiffel's pre- and post-conditions).

:-((

I'd much prefer smaller lightweight interfaces with as little 'code' in
them as possible...

> > Or, to say it differently, it is more essential
> > the a system's documentation describes faithfully what is
> > rather than what should be (but is not).
> 
> I disagree alot. I'd rather have clear documentation of intended
> behavior, rather than have the documentation change based on
> implementation decisions.

Yeah! ZSearch (thanks Michel, I did know about it but didn't express my
point very well ;-) seems like a good example of this to me. The
_interface_ deosn't seem to exist, just several implementations and no
actual documentation. I wonder if the implementations all have the same
functionality? They would if the interface was a contract...

> Please note that these points were argued extensively on the Python
> types-sig a couple of years ago.

What was the outcome?

Michel wrote:
> > However, until Catalog has a defined _interface_, I'm not even going to
> > think about starting :-S
> > 
> > Anyone know when that's likely to happen?
> 
> A couple of years ago. (hehe - sorry, had to). 

Well, sorry to correct you, but there isn't an _interface_, or at least
one that's published. 

> The Z Search Interface
> is well defined (not well documented)

ie: there isn't an interface, there's just similar (I bet they're not
identical) implementations in ZSearch, Catalog, ZSQL and ZNetwork
(whatever that is ;-)

> The 'Z Search Inteface' object is one tool in particular
> that uses it, perhaps you can in imply the interface from that since it
> is not documented.

As I said earlier, I totally agree with Jim that a weak interface like
this isn't a lot of use. What happens next time someone tweaks the
catalog and changes the functionality? Does that mean the interface has
changed? How can all the seperate implementations keep up?
I actually tried to make Squishdot implement the Z Search Interface when
I moved to using the catalog, but it appeared at the time that ZCatalog
didn't actually work properly with Z Search anyway. All of which kindof
illustrates my point :-S

The main thing for me is that the implementation is documented
somewhere, which it isn't. Of course, it'd be much better if it was a
proper interface as is being discussed here. Mindyou, it'd also be great
if python had native interface support. What does Guido think about
that?

cheers,

Chris :-)