Class t.p.r.TheirReferenceUnslicer(slicer.LeafUnslicer):

Check to see if the given token is acceptable (does it conform to the constraint?). It will not be asked about ABORT or CLOSE tokens, but it *will* be asked about OPEN. It should enfore a length limit for long tokens (STRING and LONGINT/LONGNEG types). If STRING is acceptable, then VOCAB should be too. It should return None if the token and the size are acceptable. Should raise Violation if the schema indiates the token is not acceptable. Should raise BananaError if the type byte violates the basic Banana protocol. (if no schema is in effect, this should never raise Violation, but might still raise BananaError).

'childobject' is being handed to this unslicer. It may be a primitive type (number or string), or a composite type produced by another Unslicer. It might also be a Deferred, which indicates that the actual object is not ready (perhaps a tuple with an element that is not yet referenceable), in which case you should add a callback to it that will fill in the appropriate object later. This callback is required to return the object when it is done, so multiple such callbacks can be chained. The childobject/ready_deferred argument pair is taken directly from the output of receiveClose(). If ready_deferred is non-None, you should return a dependent Deferred from your own receiveClose method.

Called when the Close token is received. Returns a tuple of (object/referenceable-deferred, complete-deferred), or an BananaFailure if something went wrong. There are four potential cases:

(obj, None): the object is complete and ready to go
(d1, None): the object cannot be referenced yet, probably
            because it is an immutable container, and one of its
            children cannot be referenced yet. The deferred will
            fire by the time the cycle has been fully deserialized,
            with the object as its argument.
(obj, d2): the object can be referenced, but it is not yet
           complete, probably because some component of it is
           'slow' (see below). The Deferred will fire (with an
           argument of None) when the object is ready to be used.
           It is not guaranteed to fire by the time the enclosing
           top-level object has finished deserializing.
(d1, d2): the object cannot yet be referenced, and even if it could
          be, it would not yet be ready for use. Any potential users
          should wait until both deferreds fire before using it.

The first deferred (d1) is guaranteed to fire before the top-most enclosing object (a CallUnslicer, for PB methods) is closed. (if it does not fire, that indicates a broken cycle). It is present to handle cycles that include immutable containers, like tuples. Mutable containers *must* return a reference to an object (even if it is not yet ready to be used, because it contains placeholders to tuples that have not yet been created), otherwise those cycles cannot be broken and the object graph will not reconstructable.

The second (d2) has no such guarantees about when it will fire. It indicates a dependence upon 'slow' external events. The first use case for such 'slow' objects is a globally-referenceable object which requires a new Broker connection before it can be used, so the Deferred will not fire until a TCP connection has been established and the first stages of PB negotiation have been completed.

If necessary, unbanana.setObject should be called, then the Deferred created in start() should be fired with the new object.

Return a short string describing where in the object tree this unslicer is sitting, relative to its parent. These strings are obtained from every unslicer in the stack, and joined to describe where any problems occurred.