[Zope3-dev] Interfaces as factories

[Nicholas Seckar]

I should have mentioned before:
  Using interfaces as factories would be a lot like
Objective-C's class clusters, except with 
configurable selection logic and better expandability.

--- Martijn Faassen <faassen at infrae.com> wrote:

>How does this relate to the use of interfaces as
adapter factories, as 
>is possible right now, i.e.:
>
>myadapter = IFoo(content)
>
>Would seem that if your factory needs arguments,
there'd be a conflict 
>with adapter factories, unless you define
construction of content 
>objects as a form of adaptation somehow. No idea
whether that is a sane 
>idea, I'll leave it to Jim and Steve who like to
consider everything as 
>a special kind of adapter. :)

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

The first usage would be the tidiest, and probably
encourage the most use because of brevity, but
__call__ is already used by adaptation. The __call__
method could differentiate between adaptation requests
and factory request, but there would likely be overlap
in some cases, so that is not terribly practical.

(Adapting an interface to a factory has a sort of
*clean* feeling, but keep in mind that factory
selection would best be based upon the init args; thus
a proxy factory would be created by IFactory's
adapter.)

[snip!]
>   * how do I find out which package provides such an
interface? I.e. 
>what is the dependency?

The interface manager could maintain a persistent file
containing the module paths to each interface. This
file would have to be updated whenever a new interface
was loaded, and also from time to time to remove
interfaces that have vanished. To find the location of
an interface, a simple python program could search the
saved file, or a web interface could be written.

This approach would an interface to have been loaded
sometime in the past for it to be in the repository. A
shell program could recurse python packages and
register all interfaces to re/create the listing, and
the interface listing would be updated when interfaces
were created.

In addition to this, a central/unified/online
interface tracker could be maintained. Thus, when
running a third party package with unmet dependancies,
the interface repository could ask the central
repository for the depending package info and print
that to a log. This would help the developer find the
packages s/he needs to install.

[snip!]
>   * I'm unable to actually run packages without the
interface 
>registration process taking place.
This is true; if you rely upon a module for core
functionality (such as object creation) then you will
require that module. However, the interface repository
package would not be extremely large; it could be made
independent of the main zope framework. To run a
package without Zope one would still require the
interface-repository module, but not necessarily a
complete Zope install.

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.

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.

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?


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail