[Zope-dev] implementing zope.component 4.0

[Gary Poster]

On Nov 30, 2009, at 3:49 PM, Charlie Clark wrote:

> Am 30.11.2009, 20:24 Uhr, schrieb Gary Poster <gary.poster at gmail.com>:
> 
>> 1) I very much like the idea of some helpers hanging around.  However,  
>> my current belief is that the factory "methods" ought to be callable  
>> objects that allow introspection of the underlying registry.  That's  
>> where the "lookup" style behavior belongs, IMO, as well as other  
>> helpers.  See below for examples.
> 
>> 2) As argued before, I think that "adapt" is an ok name for a single  
>> object, but becomes a bad name once you have "multiadapters" in the  
>> mix.  I would prefer one of the options Matthias Lehmann proposed ("new"  
>> for instance).
> 
> I have no great problem with multiadapters as long as the analogy is clear
> enough - "this adapter takes two sources..."

Well, my first issue is that the "adapter" word is unnecessary by my definitions.

Then to the multiadapter concern I raised, all my real-world examples of adapters are to adapt one object so it can be used in a certain way (to integrate with another kind of object).  Power adapters, for instance, adapt a plug (required interface) so it can plugged in to the wall (output interface).  Is there a common real-world example of this for "multiadapters"?

>> 3) I also think that "utility" is a bad name.  Is "singleton" two  
>> letters too long?  If it is, I mind "utility" less than I mind "adapter".
> 
> I don't understand this. For me a singletons is (sic) a highly specific
> programming term whereas adapters and utilities, especially in the way we
> refer to them, are not so domain specific.

Turned around, people know the term "singleton" and they do not know the terms "adapters" and "utilities".  "singletons" describe the huge majority of how we use these things.  It's something less to explain.  Making comprehension quicker is very valuable to me.

Put yet another way, how are 99+% of our "utility" usages not singletons?  If that's the case, what's the value of having to explain what a utility is?  How do you reply when the people you support say, "oh, so this is just a singleton, right?"

That said, and to repeat, I mind "adapter" more than "utility."

>> IFoo.new(a, b) # finds and returns result of call
>> IFoo.new.lookup(IA, IB) # finds and returns callable
>> IFoo.new.find(IA, IB) # get all registration information
>> IFoo.new.find_stack(IA, IB) # get an iterable of the stack all  
>> registration information for each registration for those two interfaces
>> IFoo.singleton() # finds and returns item
>> IFoo.singleton(name='baz') # finds and returns item
>> IFoo.singleton.lookup(name='baz') # same result in this case
>> IFoo.singleton.find(name='baz') # get all registration information
> 
> Interestingly this is starting to look too verbose and java like to me but
> I'm also not happy with the use of "new" or "singleton". "find" might be
> an idea if it could use introspection to gives clues as to what I might
> actually want to do with my IFoo implementers. Can you give some sample
> responses?

The majority of those were advanced, or debug usage.  That's the kind of thing that Chris was talking about, at least in my estimation if not in his :-) .  Here's basic usage.  I'll use "utility" since I'm getting more pushback on that one. :-)

``IFoo.new(a, b)`` is equivalent to getMultiAdapter((a, b), IFoo)

``IFoo.utility()`` gives you the singleton registered for IFoo.

That's the basic idea.  It's basically what Shane proposed, with the "adapter" -> "new" thing (and my squelching of "utility" -> "singleton").

What if you want to determine how you got the result that you got?  You need some additional methods.  My proposal was that you put those methods off of ``.new`` and ``.utility``.  You could also make other methods (or objects) off the interface.

In my experiments, I have the following debug and utility/advanced methods.  You would typically only look at these if you were trying to figure out what was going on, or if you were doing something tricky.

.lookup (what Chris proposed)
.lookup_all (also based on the registry call of the same method)
.find (get registration information--that is, value, required, provided, name--for the same input as lookup)
.find_all (get registration information dictionary for the same input as lookup_all)
.find_stack (returns an iterable of registrations, beginning with the one that would have been chosen, and following with the registrations that were masked by that one.)
.__iter__ (iterate registrations for output interface)
.find_for_value (returns an iterable of registrations for output that have the given value)

These are also on the underlying shared registries, with similar meaning.

>> Side, but related point:
>> I wonder if there is value in the ability to spell
> 
> Could someone please point me in the direction of the definition of this
> use of spell? Is it short for "spell it out"?

A spelling in this sense is a specific API for an idea.  I was asking about the *ability* to spell--whether this kind of usage was interesting.

Gary