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 - Zope-Dev@zope.org 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 )