Martijn Faassen wrote:
> Given some feedback about backwards compatibility, I'm leaning to the
> following adjusted scenario:
> * allow IFoo((a, b)) for multi adaptation. This breaks tuple adaptation.
> It's not as pretty as IFoo(a, b), but it's pretty tolerable and it *is*
> actually symmetric with registration.
> * deprecate a non-explicit default such as IFoo(a, default), require
> IFoo(a, default=default)
While this short spelling of component lookup is attractive and sensible
for Zopistas, I wonder if it ever really was the best idea. When a
developer encounters the IFoo() pattern for the first time, what is
he/she going to type into a search engine to find out what it means? I
can't think of any search phrase that is likely to give a good answer.
JQuery has a similar issue, but because JQuery is a smaller framework,
the JQuery folks simply put that info right near the top of their
documentation. I'm not sure we can do that quite as effectively.
For an alternate spelling, consider what happens when component lookup
fails: you get a ComponentLookupError. "Lookup" is interesting. It
doesn't yet have any meaning in zope.interface, so I think using a
method named lookup() would make code more comprehensible. You would
use it like this:
<SomeAdapter instance at ...>
>>> IFoo.lookup(a, b)
<SomeMultiAdapter instance at ...>
>>> IFoo.lookup(c, default='missing')
<MyUtility instance at ...>
When developers encounter this for the first time, they might type
"zope.interface lookup" in a search engine. That phrase has a
reasonable chance of hitting good documentation.
What do you think?
If adding lookup() is a good idea, then all we need to do is add
lookup() to zope.interface 3.x and deprecate the 2nd parameter of
IFoo(). After that, we can let multi-year evolution dictate whether
IFoo() should be deprecated altogether.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -