[Zope-dev] RFC: Python/Zope Interfaces

[Dieter Maurer]

Jim Fulton writes:
 > Dieter Maurer wrote:
 > > 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.
But this does not imply, that the contract becomes stronger,
when interface and implementation are separated.
Packaging issues do not change the contract.

I see however, that you usually will (should) start with a specification
(the interface is part of it) and then provide an implementation
(or more than one) for it.

 > > 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.
If an implementation has nothing to do with its specification,
then either the implementation or its specification is useless,
at least in relation to one another.

But, you note, that I did not speak about "a weak interface that
is satisfied by definition" but about a "somewhat weaker
contract that is met by the partners compared to a somewhat
stronger contract but violated contract".


 > > 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.
If the implementation decisions are essential: e.g.
linear versus logarithmic time complexity, I would like
to have that stated in the documentation.


 > Note also that most classes implement multiple interfaces.
 > Generating interfaces from classes trends to yield bloated
 > non-cohesive interfaces.
I may agree with this.
Though some configuration for the generation process may help
to reduce the danger.

 > Similarly, most interesting interfaces are implemented by multiple
 > classes, so nearness to implementation is not really meaningful.
It helps the implementation to adhere to the contract.

 > Please note that these points were argued extensively on the Python
 > types-sig a couple of years ago.
SIG archives tend to be non-searchable.
I, probably, will not dig in to summarize the results.
Even, if I do, this would be no garantee that I would be
convinced.


Let me stress my point of view. Maybe, we are not too far away
from one another:

  * I like clear specifications (as you do)

  * The specification has more value, when its implementations
    adhere to it (you probably will agree).

  * A documentation about an existing system is more
    valuable, when it states what is rather than
    what should be (here we may disagree).

    I usually start by studying the documentation.
    If it descibes what is, then I will recognize
    early what does not fit my requirements and
    can work around it.
    If it describes what should be, I will
    determine the deficiencies much later in my projects,
    modifications are much more difficult and expensive.

  * Having the specification near the implementation
    helps the implementors to adhere to it,
    especially with long maintenance periods.
    (Here we may disagree).

    I believe in the value of well documented
    source, in literate programming.


Dieter