[Zope3-dev] Re: Context proposal II

[Martijn Faassen]

Jim Fulton wrote:
> Phillip J. Eby wrote:
> >I'm +1 on the new proposal,
> 
> Yee ha!

My concerns remain however; I still don't like the
request's context used for all lookups unless specifically overridden in
the code.

In particular, Phillip has been asking for use cases motivating the
proposal. I have seen few so far and I agree with him that we need some more..

I wonder what other people's positions are on this. Perhaps we can
come up with a few more use cases together. As a kind of summary,
I've listed the three main points in my mind, with what I interpret to
be Jim's position (apologies if I'm misrepresenting it), along with my worries.
For detailed examples look into the thread. If any questions remain or
more examples are needed please let me know and I'll try to supply
them.

  * Jim feels that there is no problem with the request's context determining
    the lookup context of all the components which are used. Since the 
    components are looked up by interface the right functionality is still
    found, even if it is isn't coming from the containment context at all.

    I've put up a few 'data dependency' use cases up in the original
    thread as counter arguments. Instances completely flexibly connected
    with respect to their interfaces can still be dependent data-wise.
    For another argument, this time based on human imperfection, see the 
    third point.

  * If you use a component in another site, this means that your own
    site's context should provide all the components this component
    tries to look up (and recursively onward). Jim states that
    having to satisfy these criteria won't be a problem in practice.

    I haven't really gotten enough in the way of examples pro or con
    here in order to determine whether Jim is right.
    It does strike me as odd that client code that just tries to
    do a call suddenly gains such a burden.

 *  If there are problems then the code you're using is actually 
    misbehaved with respect to component lookup and use and you shouldn't be
    using it that way at all. Jim says they're "wild animals" and I
    should forget about using them.

    My worry here is that we're actually making simple use much
    harder than it should be. Jim argues that code is flawed if it depends on
    a particular instance implementing an interface and cannot use
    another instance implementing its own interface. I disagree
    (first point).

    Anyway, even if I'm wrong and Jim's right here,
    I still think I can make a case that I shouldn't be stopped
    by the system from using such flawed code. It is hard to get
    really flexible code right. It is much easier to make
    tighter connections. In practice much code written is flawed in that
    it has reasonably tight interdependencies. Note that this code is not
    buggy; it works just perfectly within its own context. It's just broken
    when supplied with other contexts. 
    
    Since mere mortals like me will be writing Zope 3 application code,
    Zope 3 application code will likely contain such dependency
    flaws as well. In Jim's proposal, the system would seem to stop
    the developer from calling into any such code from outside its own context.
    I am worried that this is a hindrance.

    Sometimes being able to use horribly flawed code is better than not 
    being able to use any code at all. In Jim's proposal it seems to me 
    that the only thing left to do when you want to use a 'wild animal' is 
    to forgo Python method calls and instead use the publisher machinery, 
    starting up a new thread as the context is thread-global..

    I'm worried also that this will affect scripters. Calling
    methods on objects in some other container is not that rare.
    This other container may be a site by virtue of having its own
    components installed (adapters, etc). Those adapters won't be
    used though if called from within another container. Does this
    mean that the scripter somehow has to deal with the reason why?

Regards,

Martijn