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

[Jim Fulton]

Phillip J. Eby wrote:
> 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?

Pretty much. Zope.app is a project. Anything in there is pretty much dependent
on everything else.  Anything we think can be used outside of the application
server, we'll put in zope.

There's nothing to say that some subpackages of zope couldn't be namespace
packages.


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

Right.

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

True, although I expect zope.app.interfaces will end up being a namespace
package.  I really think zope.app will have things that are closely tied to
the app server. If you finf bits that you think would be useful elsewhere,
then lets find a way to promote them outside of zope.app.


> I don't know how big a goal this sort of reusability is for Zope 3, the 
> project. 

It's a big goal. It was the motivation for making the zope package
a namespace package.

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

Exactly.

 > I'd like
> to have the option of not importing things I don't want or need.

So, don't import from zope.app.  If you want something from there, we'll
find a way (we, including you ;) will find a way to promote it out of zope.app.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org