[Zope3-dev] Re: Interfaces as factories

[Philipp von Weitershausen]

Nicholas Seckar wrote:

> Instead of calling an interface, ie.
> IContact(first="Nicholas", ...)
> We could adapt the interface, then call that:
> 	IFactory(IContact)(first="Nicholas", ...)

I'm a bit skeptical about having interfaces function as factories. 
However, much like anything else, this problem can be solved with 
adaption, like you suggested, thus leaving interface semantics where 
they are. We currently register factories as utilities with the utility 
service, but nothing prevents you from making factories adapters from 
IInterface to IFactory so that your above mentioned code would perfectly 
work.

You've mentioned something like a creation request upon which the 
interface should decide which implementation to instanciate. Whatever 
that instanciation request may be, the logic that is based on it feels 
misplaced in zope.interface. Again, adaption is the solution (as always 
;)), to be more exact: multi-adaption:

 >>> request = FileCreationRequest('application/msword')
 >>> factory = queryMultiAdapter((IFile, request), IFactory)
 >>> file = factory()
 >>> file
<__main__.BinaryFile instance at 0x3426233>

This way, factories would be multiadapters adapting a tuple of 
(IInterface, ICreationRequest) objects to IFactory.

> In truth I expect this type of dilemma to proliferate
> as Zope 3 ages. Zope has always been a web-development
> framework, but Zope 3 is now introducing features that
> can be applied to any Python project: it's becoming,
> in some aspects, more of a Python framework.

Absolutely, Zope X3 is a framework for Python developers. This is not a 
coincidence, but very much intended.

> One example of this is the component model; while Zope
> 3 is the main (only?) project using it at this time,
> there are other projects which could benefit from it
> as well. Perhaps it would make sense to split Zope 3
> into the Zope core and app, and install the core into
> Python's site-packages. Perhaps not, though; I'm
> certainly not the one to say.

Well, apart from the place where things are installed, a separation of 
reusable and Zope-specific packages has been made since the beginning. 
All packages starting with zope.* can essentially be reused outside 
Zope. That includes zope.interface and zope.component, the heart of the 
Component Architecture. I know that Twisted will be at least using the 
former in future versions and will thus be using a standalone 
distribution of zope.interface, which will also be introduced to 
packaging systems like Debian. I could imagine that sooner or later, the 
same would be possible for zope.component.

> Regarding implementing the interface repository and/or
> interface based creation, does anyone have any
> comments? Should we make a wiki page? Does anyone have
> a definite NO for a specific reason?

Well, I'm still wondering about real use cases. The file example is a 
bit too trivial to convince me. Maybe you can lay out a formal proposal 
on the Zope3 wiki (http://dev.zope.org/Zope3).

In any case, you could implement this using adaption like you suggested 
yourself already and provide it in a separate package. I would 
definitely be interested to look at a different factory approach...

Best regards,

Philipp