[Zope3-dev] Separate package trees for presentation and interfaces

[Phillip J. Eby]

At 09:29 AM 12/14/02 -0500, Jim Fulton wrote:

>I propose that interfaces be given their own hierarchy within a *project*. 
>This means
>that the zope.app would have a package/module tree rooted at 
>zope.app.interfaces.
>
>Note that projects that fit in a single package will generally have a 
>simple interfaces
>mdoule, rather than an interfaces package. For example, the contact 
>example would
>have a single interfaces.py file, rather than an interfaces package.
>
>With this change, the adapter-service-related interfaces would live in:
>
>   zope.app.interfaces.service.adapter
>
>rather than:
>
>   zope.app.service.adapterinterfaces
>
>Note that, for a separate Zope top-level package, like schema, the interfaces
>would go in an ordinary interfaces module, like zope/schema/interfaces.py.

Does this then mean that "zope.app" is a project, "zope.publisher" is a 
project, and so on?


>The advantages of providing a separate interface hieratchy are that:
>
>   - Individual modules remain cohesive and have simple names
>
>   - View developers don't have to navigate the implementation hierarchy to
>     find the interfaces they need.
>
>The disadvantage of this approach is that absolute imports will be 
>necessary in
>many cases where relative imports can be used otherwise.  This is not so 
>much of
>a problem now because relative imports are currently implicit and, thus, 
>frowned upon.
>If Python introduces an explicit relative import syntax, then the inability to
>use relative imports will be more significant.
>
>So, unless someone convices me otherwise, we'll move forward with separate 
>presentation
>and interface hierarchies.

The main potential disadvantage I see to this is in segmented reuse.  If I 
want to use some part of 'zope.app', I have to include the 
'zope.app.interfaces' subtree.  Of course, it may be that there is nothing 
I can usefully separate from 'zope.app'.  Further, if we are using __init__ 
as the API export module of the zope.app.interfaces package, then there is 
no way I can import just the interfaces I need, either.

I don't know how big a goal this sort of reusability is for Zope 3, the 
project.  I know it's a big goal of mine, as an application developer.  The 
all-or-nothing nature of Zope 2 is a substantial deterrent to its use, and 
I expect that in Zope 3, 'zope.app' is going to be the place where lots of 
stuff that I don't care about is going to live.  I'd like to have the 
option of not importing things I don't want or need.