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  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to