[Zope3-dev] Never mind. :) (was Re: Need help with jargon)

[Jim Fulton]

Steve Alexander wrote:
> Hi Jim,
> 
> I'm following up on the conversation we had just now on the  #zope3-dev 
> irc channel.
> 
> Steve wrote:
>  >> So, compared to other languages / systems, utilities are a bit like 
>  >> globals, multi-adapters are like multimethods and pep246 adapters 
> are >> adapters.
> 
> Jim wrote:
>  > That's a good summary, with the added twist that the parts are
>  > configurable outside the program.
>  > Pretty much the only thing that utilities add over, say modules, is:
>  >
>  > - Pluggability
>  >
>  > - Limited searchability/listability, which turns out to be useful.
>  >   We can list them in UIs for example.
> 
> In that case, let's call utilities "singletons", as that's the role they 
> play in an application.

I don't like the word singleton.  To the few who know what "singleton"
means, it has a different meaning than whet we're talking about here.

I'm open to a different word, but I don't think that utility is
all that bad.  I'll note that we've adopted the word "tool" to encompass
services and utilities.

 > Let's call multi-adapters "utilities" as PJE
> suggests,

And as I responded to PJE, I don't like the word utility for that.
In particular, while I want to draw a distinction between PEP 246
adapters and multi-adapters, I don't want to draw a strong distinction.
They are more similar than they are different, IMO.  I'm really looking
for different adjectives, except ....

An "adapter" is an object that provides an interface for other objects,
That term encompasses PEP 246 adapters and multi-adapters.  In fact, there
really isn't a difference between PEP 246 adapters and multi-adapters.
The difference lies in the lookup algorithm.  So, perhaps we don't need
different names for the components so much as we need different names for
the lookup API. Doh.

For PEP 246 adaptation, we largely have that already. PEP 246 adapters are
looked up via interface call *except* in the special case where we need to
specify a specific location to look them up in.  Perhaps all we need
is zapi.adapt (zope.component.adapt) to do PEP 246 adaptation in those rare
cases where we need to provide a special location to look up an adapter.

What we need is a different verb for multi-adaptation, remembering that
multi-adaptation allows not only multiple inputs but multiple name-qualified
components. I'll note that, while we need multi-adaptation, it will be far
less common that PEP 246 adaptation.  Perhaps "multiGetAdapter" and
"multiQueryAdapter"?

I'll note that zero-object multi-adapters provide a confusing edge case.
At one point, I was going to consider *these* to be utilities.  I was going
to do away with the utility service and just use adaptation of no objects to
do utility lookup. I decided against this because that would introduce
a discontinuity in registration. Zero objects adapters would have been
registered with instances, but non-zero-object adapters are registered
as factories.  I finally decided that it was cleaner to always register
adapters as factories, even though that would greatly limit the usefulness
of zero-object adapters. I still like having zero-object adapters for
completeness and because there is a use for them. They provide a way to
register factories that are looked up based on the interfaces of the
objects they create.

So, in summary, I propose:

- Stick with the term "utility". I'm open to a different word if we think
   that "utility" is confusing *and* we can come up with a much better
   term.

- Stick with the term "adapter" for components that adapt, including
   components that adapt multiple or zero objects.

- Eventually, introduce a zapi.adapt (zope.component.adapt) that has the semantics
   of pep 246 adapt with the addition of being able to specify a location to look up
   an adapter.  We will deprecate getAdapter and queryAdapter.

- Deprecate getNamedAdapter and queryNamedAdapter, as these are just special cases
   of getMultiAdapter and queryMultiAdapter.

- Rename getMultiAdapter and queryMultiAdapters to reflect that we are not
   getting a different kind of adapter so much as getting adapters differently,
   realizing that, while this is an important case for some applications, we
   don't think it will be very common.  Possible names include: "multiGetAdapter"
   and "multQueryAdapter".  (I'd sort of like to use a verb, as in: "multiAdapt",
   but then we'd need a query flavor. Using the presence or absence of a positional
   default argument doesn't work here because we have a name argument which will
   default to ''.)

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org