Re: improving the utility and adapter lookup APIs

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


_______________________________________________
Zope-Dev maillist  -  [email protected]
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )