[Zope3-dev] Context and Component Lookup

[Martijn Faassen]

Jim Fulton wrote:
> Martijn Faassen wrote:
> >>Right, I understand your point.  My point is that it shouldn't matter
> >>because the interactions are through a common interface.
> >
> >That doesn't make sense to me. I can have two views, A and B, which
> >have the same interface and are associated with the same content
> >object interface. But it certainly matters which view is shown.
> 
> To whome does it matter?

To the person looking at the view, for one. To the developer who has
to figure out he has to supply this view all of a sudden in his
own context, even though it's not part of his package, just in order to use
some other component that happens to require that view (or adapter
or whatnot).

Actually there's another problem; you don't know *which* components the
object in another context may need; object A implementing IFoo may need
adapters to interface IBar and IBaz, while object B implementing IFoo
may very well need adapters to interface IQux instead. And if your
context is going to passed to them, that context needs to know about all
three adapters... Or am I missing something here?

>  I suggest that it is often not the code that looks
> up the views that cares. The system designer cares.

Yes, as a system designer I care that I don't have to satisfy a lot
of criteria in my context just in order to use an object somewhere
else. In my mind, that object has its own context.
 
> >What if I have two interfaces that do some storage, one using a relational 
> >backend and the other the ZODB? Exact same interfaces but I certainly don't
> >want to switch from one to the other just like that.
> 
> Why? What difference does it make. The client of those interfaces shouldn't
> care.  If the client's do care, there's a problem with the interfaces.

Does that mean storage needs to be explicit in the interface? If I'm telling

somewhere.fridge.store('cheese')

from my context, where I have a utility that implements IFridgeStorage
using a ZODB backend, and then I go do this from some other context where
the utility is supplied that uses a relational backend, I'll get
confused, right?

> OTOH, parties assembling a system may care very much which components are
> used, but these preferences are expressed in the site configuration, not
> in the component code.

So if you have:

  * site X which maintains state

  * The way the state is managed depends on component lookup

  * site Y and Z both supply different components which influence state
     management in their own contexts.

  * site Y can now affect the state of site X in a way that may be invisible
    to site Z, and vice versa.

I'd expect instead X to have its own context with components and that site
Y and Z defer to this when dealing with X. Only if I move something from
X to a different context will X's behavior be modified.

Perhaps I'm just completely missing the point, but I see difficulty
both with this, and with the requirement that I suddenly need to 
supply a lot of components that my site doesn't directly deal with,
just in order to use a different area of the system. 

If I'm going to show a view for a content object that's in a different 
folder which supplies its own views, I now have to supply those views myself in
order to make things work. This seems odd to me; I should only have to do that
if I'm going to use this content object in my own context, I thought.

[snip]
> >But if using an alternate component means I need to *know* which components
> >are going to be looked up by that alternate component so I can actually
> >supply them in my context, then *that* breaks encapsulation. I shouldn't
> >have to know which components are looked up by another component in
> >order to use it. It's specified nowhere in the interface. Are you saying
> >this should be specified in the interface?  
> 
> We need to understand that there are different levels of abstractions.
> Interactions between individual components are specified through the 
> interfaces.
> 
> To understand how to assemble components, however, you do need more than
> the interfaces. There's a book on component-based UML that, unfortunatly, I
> can't lay my hands on at the moment. It talks about component 
> specifications.

Hm, perhaps this is the confusion. In my mind there's a difference
between assembling components and just using them. If I use a 
component I don't need to worry about what components are used in
its assembly.. Perhaps such separation between use and assembly is
a fallacy of mine?

I mean, naively thinking I think it should
be possible to use (call a method on) an object without having to 
worry about how this object interacts with other objects. I'd call
this use.

If I do have to worry about it (as I have to supply components *it*
wants to use) in my own context, I have to worry about assembly each
time I call a method in a component I don't control. This seems scary.

> The component specification talks about both the interfaces provided by a
> component *and* the interfaces required by a component.  The component
> specification is of interest to the assembler of the components, *not*
> the author of them.

Hm, I'm reasoning from the case where I, the author of components, also have
an idea of how they're assembled. In fact, I may be actually writing
an application, worrying about assemblages and so on.

I am also assuming that some other area of the application is created
and assembled by someone else. Now I want to interact with this other
area. There are multiple author/assemblers. 

>From the pure assembler point of view.. Imagine I have this assemblage
of components. Now I want to hook up one component to another component
which is in someone else's assemblage. In your model my context matters, so
this would mean that I would need to replicate a version of this other
assemblage in my own assembly before it all works. Is that a correct
interpretation?

> >>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.
> >
> >What if there's a data dependency?
> 
> I don't know what you mean. Any dependencies between infividual components
> should be described by the interfaces they interact through.

Imagine there's a site X, which contains objects. It somehow has a need
for a count of those objects, and looks up a service which maintains this
count.

Now I have a site Y, which uses facilities in site X by calling into
it. I have to supply a version of the counting service in site X. But
this version of the service won't have the correct count.

I guess this can be solved by 'pushing up' the service so that it
is shared by X and Y both.. This means that site Y cannot properly
use site X unless it knows that site X is still satisfied with the right
shared components; if site X has a local counting service this becomes
rather hard, though..

Anyway, I may be misunderstanding your proposals and my suggestions
may therefore not make any sense..

Regards,

Martijn