[Zope3-dev] Allowing views to be registered for classes ratherthan interfaces.

[Martijn Faassen]

Jim Fulton wrote:
> Garrett Smith wrote:
> >Were it me, I'd throw the interface into the same module -- I'm an XPish
> >fan, so I like to get things working then evolve.
> 
> Yup. As this discussion proceeds, I'm becoming convinced that
> interfaces that are expected to have a single implementation should
> live close to their implementations.

If it's of any use, I'm leaning into this direction as well, though
I suspect a locally present interfaces.py module is still going to
be easier to read than scattering the interfaces throughout the other
modules.

Interfaces can probably have a different status of being more or less
public:

  * completely private interface -- a view on a class may be fine. No
    other client code is expected; i.e there really *is* no client code
    as this code is very interdependent.

    In code evolution, this could be the very early stage of the code.
    A scripter might typically start out with this code. It can also
    be a stage in prototyping or be done by someone in a messy rush.

  * interfaces inside implementation modules. A private interface that
    happens to be documented. This interface should not be imported by
    an other module or perhaps also not referred to by ZCML. The only 
    external systems that can pick up on it are introspection/documentation
    tools.

    In code evolution, this could be the early evolution of the code. 
    The interface is perhaps not fully fleshed out yet. Or it may be
    mature but the programmer wishes to be friendly and tries to keep this
    information away from places where it could only confuse with an
    overdose of information mostly related to one particular implementation.

  * Public. The interface is expected to have multiple clients, but
    does not expect to have multiple implementations. This interface 
    is in the interfaces.py module in the same directory as the implementation.

    In code evolution, often this is generic enough. Of course it is 
    possible to skip the previous steps and leap here directly. This
    can be done by an experienced programmer when the multiple-client
    requirement is clear.

  * Published. The interface is expected to have multiple implementations.
    This interface is in the separate published interface tree of this
    entire package. Pluggability is very important. A framework is
    designed where multiple implementations of the same interface are
    essential to the functionality.
 
    Some code will evolve towards this stage eventually as the requirements
    for flexibility become more clear. Lots of code never does reach this
    stage, though.

    A domain expert with related implementation experience may reach this
    stage right away. Another case would be where existing standard
    interfaces are being implemented.

Regards,

Martijn