Martijn Faassen wrote:
Hi there,
Hi Martijn,
Jean-Marc Orliaguet wrote:
some packages have an interfaces.py file others have a "interfaces"
folder, others have the interface definitions in the implementation
code itself ...
The pattern changed over time during Zope 3 development. In my current
opinion, interfaces.py should usually be able to accomodate all the
interfaces of a package. If interface definitions are to be 'private'
then they can be in the implementation code, but such privacy is very,
very rare in practice.
Jim mentioned to me that only public and official interface
definitions should be listed in 'interfaces', the others should be
defined inline with the implementation - are there guidelines to follow?
Don't know. I think the best rule would be to make the interface
public unless you have a very good reason not to do so, not the other
way around.
This is where I'm standing: I have lots of interfaces that don't make an
API. There are used by a bunch of classes to make it possible to
register adapters, interface types, utilities, etc. There are more or
less like marker interfaces, or schema definitions that are not supposed
to be used "publicly".
They are "private" interfaces that are used to glue together components
but in a way internal to the application. By having them in
"interfaces.py" I feel that I'm making them more official than they need
to be, they're is some sort of extra ceremony in it.
For the public API, it feels like the right place to have them, but it
is a commitment as well, and there is no way to make a statement like
"don't use these interfaces, they are subject to changes". I don't like
the underscore imports either.
I think there should be two different patterns based on the nature of
the interfaces that get defined (private / public)
regards
/JM
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
