[Zope-dev] improving the utility and adapter lookup APIs
Martijn Faassen
faassen at startifact.com
Sat Nov 28 06:30:21 EST 2009
Chris McDonough wrote:
> Martijn Faassen wrote:
>> Hey,
>>
>> Christian Theune wrote:
>> [snip]
>>> Another option would be to provide a backwards-compatibility mode of our
>>> code which can be switched on and off.
>>>
>>> Your notion of bringing the component lookup mechanics closer to being a
>>> "language feature" is very intriguing and I like it a lot. However, if
>>> we do so, I'd like us to not having to resort to second-best
>>> spelling/implementation due to backwards compatbility. I'd like to work
>>> pretty hard on doing the implementation we want because it's a good
>>> implementation and then make backwards compatibility work. (I know, I'm
>>> a dreamer ...)
>> I'd be in favor of an API based off calling the interface directly for
>> everything *if* we can come up with a backwards compatibility story somehow.
>
> Just as a data point, I forgot to hook "adapter_hook" in BFG (and I still
> haven't), which means that the IFoo() sugar doesn't work. Nobody noticed, even
> though lots of folks who use BFG also use the ZCA global API.
>
> I'm not implying that this means it's not useful or convenient for old hands.
> But the old hands don't really need it.
Interesting. If you mostly do multi-adaptation (and utility lookups) you
won't notice it as we know multi adaptation cannot be done with the
adapter hook. Was this the case?
I really have trouble remembering the lookup APIs in zope.component
myself. People in my experience actually *try* to do multi adaptation
using the IFoo adapter hook and then get confused because it fails.
> If the primary goal is to increase adoption, I think further abstraction of
> stuff behind nicer calling conventions won't help improve matters: people
> really need to understand the "A-through-Y" concepts before they can jump to
> "Z"; promoting "Z" before better explaining "A-through-Y" first will only add
> more confusion. We currently do a pretty poor job of explaining A-Y, at least
> in all the documentation I've read. I think this implies that we need to break
> down the concepts into more consumable layers and document each of them before
> we add more abstraction.
(as I said elsewhere): My primary goal here is to improve life for those
already using the APIs. But I agree we should definitely improve
documentation for it too as we go along, and I will help with that.
[I think there are decent explanations of at least adaptation floating
around, but not along with zope.component, and important bits such as
utilities are probably underdocumented]
Regards,
Martijn
More information about the Zope-Dev
mailing list