[Reality] collectionary

[Glyph Lefkowitz]

Notes from IRC.

Since certain systems may want to involve themselves in the collect()
process but not do anything with containment or physical relationships,
we need a way to hook into that WITHOUT implying physical relationships.

For example, a "frotz" spell may want to cause things to give off a
"glow", and the "glow" is actually an object, but not physically
contained or an exit from the object, but logically associated with it
in an abstract way.

This means that ICollector needs some extra methods to provide these
hooks, e.g. the link and unlink methods currently on container.  In
order to distinguish between these "external" uses, where only the
system that places the link should remove it, and "normal" uses, where
there is a defined API for adding and removing objects in some
conceptual, usually physical relationship, we should have several
different implementations of find and more, but only one implementation
of link and unlink.  A Collector base-class which implements link and
unlink in the canonical way that Container currently does should move
into simulacrum.  Container should subclass that to provide a
location-aware containment graph.  Room should subclass Container to
provide an exit-aware containment graph.

We should also eliminate distance from the collection process as much as
possible.  Distance should be part of a criterion, which will be managed
by Room's exit machinery to propogate and add distance through exits. 
Distance should be added, I think, by using proxies.  The proxy returned
by a room would return "too far away" proxies or Refusals for
_contained_ objects from .find() and .more(), but _exits_ would not be
returned at all.  The "too many hops" limit is really to prevent
griefing the containment system, and should not be mixed up with the
"too far away" limit.