-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martijn Faassen 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.
>
> I'm in favor of calling the interface. I'm also in favor of unifying
> adapter and utility lookup.
+1 to both. I think #3 is the best overall compromise, perhaps
eventually migrating to #4 after all use of positional default has faded
away. Making tuple adapter lookup use the non-sugar spelling seems a
pretty low cost.
> On the back end, I'm also in favor of allowing utility creation by
> factory (or "null adaptation") and allowing instance lookup for
> instances ("contextual utility lookup" or "adaptation to an instance").
> I think four ways to retrieve an object of the right interface
> (combining factory/registered instance and lookup globally/lookup for an
> instance) is a good argument *against* distinguishing between creation
> strategies or "connection to adapted object or not" in the API.
One easy way to handle this seamlessly is to check the registered
object: if it implements (rather than provides) the interface, then
call it, otherwise just return it. Folks who use factories which don't
declare what they implement would need to adjust if we adopt this approach.
Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tsea...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksVSGwACgkQ+gerLs4ltQ53awCff+U4Pf836NucmWnLCCrvrwul
kC0An3UG6NT51numMPPh78DCqSK9HrJy
=tq4A
-----END PGP SIGNATURE-----
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
