[Zope-dev] RFC: Python/Zope Interfaces

[Jim Fulton]

Dieter Maurer wrote:
> 
> Michel Pelletier writes:
>  > Also, defining the interface seperately keep the two things apart,
>  > impementation and interface, and doesn't allow you to sneak in a new
>  > method unless you also sneak it into the interface, thus making a
>  > stronger "contract" with the user.
> I am a bit astonished by this statement:
> 
>   I know the "design by contract" concept from Bertrand Meyer,
>   the Eiffel developper.
> 
>   In Eiffel, essential parts of the contract, among others
>   method prototype, pre- and post-conditions as well as invariants
>   are build directly into the language.
>   A documentation tool extracts these parts
>   from the source to generate the interface, for people
>   that are only interested in how to use the class/method.
> 
>   Programms can be executed in a way, that the various
>   (executable) contract parts can be checked at runtime.
>   *THIS* provides for quite a strong contract.
> 
> I cannot see, why the separation of interface and implementation
> should make the contract stronger.

The interface *is* the contract. If someone builds a house
for me, I don't want the house to *be* the contract. I want the
house to adhere to the contract.  Interface/contract and implementation
are two qualitatively different things.

> I do see, however, that it
> makes it more likely to be broken by the implementation.

I don't think it makes it more or less likely. Of course, 
if the "interface" is always derived from the implemenation
then the two will be consistent, but this is not 
terribly useful.

> 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. ;)

> 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).
 
> If you want to prevent your implementors to change the
> interface specification, generate the interface for the
> implementation and compare against your master copy.
> 
> In my view, it is better to have a somewhat "weaker" contract
> that is met by the partners than a "stronger" contract that
> is violated.

We disagree then. A weak interface that is satisfied by definition
is nearly useless to me.

> 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.

Note also that most classes implement multiple interfaces.
Generating interfaces from classes trends to yield bloated
non-cohesive interfaces.

Similarly, most interesting interfaces are implemented by multiple
classes, so nearness to implementation is not really meaningful.

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

Jim

--
Jim Fulton           mailto:jim@digicool.com   Python Powered!        
Technical Director   (888) 344-4332            http://www.python.org  
Digital Creations    http://www.digicool.com   http://www.zope.org