[Zope3-dev] Context and Component Lookup

[Jim Fulton]

Phillip J. Eby wrote:
> At 10:09 AM 8/7/03 -0400, Jim Fulton wrote:
> 
>> Phillip J. Eby wrote:
>>



>> I see the point you are making. You are saying that a bit of code (e.g. a
>> method) should control where the search for components it looks up take
>> place, rather than the client of that method.
>>
>> What if the method doesn't care?  In some cases, the method actually
>> wants to use the callers context.
 >
> 
> Then shouldn't it use one of its parameters, that is documented in the 
> interface as being used for the lookups? 

It might, but I think that that innecessarily clutters the interface.
Such a requirement would end up being rather viral, as you's end up including
the argument in nearly every call just to make sure you had the context
when you needed.  I think this is a case where some sort of global facility
of more appropriate.


 > I'm saying that "doesn't care"
> isn't really an option, because if the method doesn't care, then its 
> caller probably does.  It should be explicit, and it should be 
> documented.  If the method doesn't want to guarantee what context it 
> will use, that should be documented too.

I suggest that:

- Most of the time the not caring will be the most common case

- That, in any case, whether you care is mostly an implementation decision.
   We know that objects that do care can often carry their context with them.

...

> IMO, having a context is just a "cost of doing business" with a placeful 
> CA, and a very reasonable one under most circumstances.

IMO, that cost is too high.


>>> Okay, let me see if I understand.  What you want, is that code that 
>>> calls Z3CA functions like getAdapter, getUtility, etc. should not 
>>> have to know what "context" to use.  Or, in other words, objects 
>>> should be able to use the Borg's communication system without needing 
>>> implants.  :)
>>
>>
>> Yes, as long as the code doesn't care where the component comes from.
> 
> 
> That's the bit I don't get; if they truly don't care, what's wrong with 
> using the global context?

That's affectively what I'm saying, except that I'm allowing the application
to choose a specific global context for a request.


>>> So, if you don't have context, use only global services.  Aren't most 
>>> Z3 services globally registered anyway?
>>
>>
>> But that defeats local customizations.
> 
> 
> So then you *do* care...

There's an inside view of components and an outside view. Individual
components generally don't care what they are connected to as long
as the party assembling components cares very much about what is
connected to what.

>> I don't want to make context management to be a prerequisite for using 
>> the
>> component model.
> 
> 
> Fair enough.  I think that:
> 
> 1. it *is* a prerequisite anyway, you're just making it implicit

No. The responsibility is lifted from the component to the
party assembling the application.

> 2. it would be better to be explicit, just make it as painless as possible

Saying that we don't care *is* being explicit. It explicitly
says that control lies elsewhere.

> 3. If you have to have objects obtain a context implicitly,

Don't worry. We won't do that.  See my new proposal.

...

> Interfaces by themselves are not sufficient. 

They are sufficient for concerns of the code lookuing up the component.


 > You already demonstrated
> this by saying "but that defeats local customizations",

No, the application controls the default lookup strategy to meet the needs
of local customization. This is a system configuration issue.


 > and by your
> earlier thought about event services. 

This is a different case.  Look at the new proposal.  I suggest that
it should be possible for code to control component lookup when it needs to.

...

>> In general, I suggest that components don't and shouldn't care what
>> other components they get hooked up to as long as those components 
>> satisfy
>> their contracts.
> 
> 
> I agree.  But the *consumer* of the component, or creator of the larger 
> work that contains the component, may very much care what suppliers are 
> connected to that component, because they are constructing a larger 
> thing with its own desired invariants. 

Sure, but that is controlled at a higher level, not in the individual
component implementations.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (703) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org