Gary Poster wrote:
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"?
I have a Roku player (great device, BTW). It streams video from Netflix and other sources. It takes two inputs (network and power) and produces one output (a video signal). I could call the device a multi-adapter, but the power input is so simple and reliable that I forget about it. Most of the time I think of the Roku player as a simple adapter from Internet packets to a video signal, but electrically, it's definitely a multi-adapter. Note that the network signal for a Roku player varies wildly, while the power is either ~110VAC or ~220VAC. Multi-adaptation works best when it has similar characteristics, I think. It's safe to allow one of the inputs to multi-adaptation to vary a lot, but to keep developers sane, the rest of the inputs should be more predictable. I think getMultiAdapter((context, request)) is OK because most web sites have only one or two request types.
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.
Do you intend to change the API names in zope.component, then? For example, getUtility -> getSingleton? That might be possible, but no one has suggested it before (AFAIK), and I think it's implied by your suggestion.
``IFoo.new(a, b)`` is equivalent to getMultiAdapter((a, b), IFoo)
Using "new" for a name could be a problem for Jython and IronPython users, since new is a keyword in other languages. Shane