[Zope-dev] summary of discussion was: adapter vs factory Re: implementing zope.component 4.0

[Lennart Regebro]

On Tue, Dec 1, 2009 at 14:21, Martijn Faassen <faassen at startifact.com> wrote:
> Hi there,
>
> I'd like to summarize the options I've seen appear in the discussion so far.
>
> We have the following options:
>
> 1) introduce a new method, such as "instance()" or "lookup()" on
> instance. It unifies utilities with adapters. We can make it do whatever
> we want without worrying about backwards compatibility.
>
> 2) introduce several new methods that distinguish between utility and
> adapter lookup. We can make them do whatever we want without worrying
> about backwards compatibility.
>
> 3) call the interface, which unifies adapter and utility lookups. Use
> tuples for multi adaptation. We think could make this work without *too*
> much backwards compatibility issues (pending research on how prevalent
> tuple adaptation really is). In the long term we can even map out a
> deprecation strategy that can smoothly migrate us to a "multi argument"
> approach.
>
> 4) call the interface, which unifies adapter and utility lookups. Use
> multiple arguments for multi adaptation. The backwards compatibility
> obstacles are largest here as we already have the "default" argument.
> We'd need to introduce multiple "modes" to selectively upgrade.

You missed:

5) Call the interface for adaption, and something else for utility
lookup, with tuples for multi-adaptation.

6) Call the interface for adaption, and something else for utility
lookup, with multiple arguments for multi-adaptation.

7) Do nothing. ;)

I'm minus lots for any unification of adapters and utilities. Since a
utility does not adapt anything, and adapters do, all they have in
common is that they implement an interface. Since in some sense, all
objects implement an interface, we have reinvented the object. That's
going to confuse the heck out of everyone. It's a very bad idea.

If tuple adaption is common, which I doubt, I'm +1 for 2. If tuple
adaption is uncommon, I'm
+1 for 5.

I'm also:

-0 for 6
-1 for 7
-lots for the rest

> If I look up a utility I wouldn't want to care whether it happened to be
> a previously registered instance or a factory created one. If I look up
> an adapter I wouldn't care whether it happened to be a previously
> registered instance either. In fact, returning a previously registered
> instance can be very well implemented using a factory. (In fact, this
> suggests to me we should actually explore implementing instance
> registration in terms of special factories.)

Making it less common to have to keep track on when you need factories
and not would be a definite benefit.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64