[Zope-dev] RFC: Python/Zope Interfaces

[Michel Pelletier]

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. I do see, however, that it
> makes it more likely to be broken by the implementation.

The "contract" is a policy.  The mechanisms of interfaces should not
require that the policy be "strong" or "weak".  This is up to the
contractor.  I'm not sure if you are making these statement because you
disagree with the current proposal or because you disagree with what I
said above.  What I said above was just a scenario, not necessarily any
position I advocate.

The current python interface proposal makes no statement on the strength
of a contract.  It sounds like you want your contracts to be strong,
fine, but Python has no explict compile-time or run-time interface
enforcement.  The proposal in question is just trying to define how
interfaces are defined, created, implemented, and used.  Strong
contractual enforcement is a minor, policy-specific decision.
 
> It is a very good thing to have the specification very near
> to the implementation -- as a permanent guide to the
> implementor. 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).

Maybe.  I disagree in this case: this proposal states that interfaces
are discoverable documentation, not language or policy enforcement.  The
less they can be tied to specific policies the more flexible they can
be.  Keep in mind, if you want run-time interface enforcement, you can
*allways* add it with mxProxy or some other mechanism.  If you *don't*
want run-time interface enforcement and we made it a requirement, you'd
be stuck.  You can allways add, but you can rarely take away.
 
-Michel