[TransWarp] Re: [Zope3-dev] EventService, references, and subscription semantics

[Steve Alexander]

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.

I need to model this later to fully understand it.


I don't think this covers having a manager in an object's context 
provide its reference.

That's why I have a distinct IReferenceGeneratorForContext utility in 
the model in my last email.

--
Steve Alexander