[Zope3-dev] EventService, references, and subscription semantics

[Phillip J. Eby]

[dropping the Transwarp list from this sub-thread, since it's only about 
the Zope Component Architecture issues]

At 12:54 PM 2/26/02 +0000, Steve Alexander wrote:
>Phillip J. Eby wrote:
>>Okay, maybe I'm missing something, but it seems to me like the simplest 
>>decomposition would be:
>>1. 'IReferenceable' - interface with a 'getReference()' method, returns a 
>>reference to the referencable thing.
>>2. 'IReference'  - subclass of IReferenceable, whose implementations' 
>>'getReference()' methods return 'self'.  Includes a 'dereference()' 
>>method, as well as '__eq__()' and '__hash__()' (general comparison 
>>doesn't really make sense for references, but dictionary lookup and 
>>equality checking would be useful).  'IReference' objects should be 
>>immutable and pickle-able, but should probably *not* be Persistent (the 
>>overhead would be wasteful).
>>3. Things that need references, use 'getAdapter()' to get an 
>>'IReferenceable' implementation for the thing they want a reference to.
>>4. You're done.  :)  Since 'IReference' is a subclass of 'IReferencable', 
>>if you were passed a reference, you've got what you need.  If you didn't 
>>have a reference, then you'll get something that can give you one.  All 
>>the lookup policies that y'all are talking about can be encapsulated in 
>>the adapter that implements IReferenceable, and configured via the normal 
>>channels.  If 'getAdapter()' is insufficiently placeful, make the adapter 
>>do placeful lookups and delegate to the appropriate authorities.
>
>[snip]
>
>I don't think this covers having a manager in an object's context provide 
>its reference.

Such a facility can be encapsulated in an adapter that provides 
'IReferenceable'; it doesn't need to be (and IMHO shouldn't be) in the core 
usage pattern.  An object which wants an 'IReference' should be insulated 
as much as possible from the mechanics of *how* to get it.  The how is a 
policy, and therefore should be *behind* an interface, not in front of it, 
if you see what I mean.

It may be that 'getAdapter()' is insufficiently placeful to make this 
work.  My understanding was that 'getAdapter()' was intended to be 
placeful, but last I looked at the Z3X code base, it was placeless.  I 
don't know if the intention is to correct that, long term, or whether my 
understanding of the intent or plans is flawed.