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. 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. - C _______________________________________________ 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 )