Martijn Faassen wrote:
> Hi there,
Thanks for doing the summarise-and-move-it-on job so well, Martijn. It's
really important.
> 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.
I find the idea of trying to conceptually reconcile adapters and
utilities pretty weird. They are quite different concepts. Searching for
one over-arching metaphor will probably land us in an even more
conceptual "applies-to-everything" situation.
I've spent the past few years explaining adapters and utilities to
people as two fundamental types of components. I'd really rather not try
to bring it "up" one level to explain something more generic (and thus
less specific/example-friendly).
I could be convinced otherwise, I'm just saying that I don't see why
trying to "unify" these two things is important.
> 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.
If all you mean by "unify" is "more consistent API", then +1. I saw
other things in the thread related to trying to treat the two as
different types of the same fundamental thing, which I think we want to
avoid.
> 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.
+1, though I think the multi-argument thing is still going to be wrong
in the future, and won't bring enough benefit for the pain it will
cause. Even if by then there's no BBB to be concerned about, it's still
a change, and it still breaks documentation.
> 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.
-1 (aka "minus a lot"), as I've said before.
> I'm in favor of calling the interface. I'm also in favor of unifying
> adapter and utility lookup.
>
> On the back end, I'm also in favor of allowing utility creation by
> factory (or "null adaptation")
Can you summarise what you mean by this? The thread is so long...
> and allowing instance lookup for
> instances ("contextual utility lookup" or "adaptation to an instance").
My brain hurts... examples?
> 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.
I'm afraid you've lost me. Four ways sounds bad, though. ;-)
> 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.)
Heh, I used the "shared adapter implementation" as an example of custom
factories in
http://plone.org/products/dexterity/documentation/manual/five.grok/core-components/adapters
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
_______________________________________________
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 )
