I was thinking recently about Imagination, and the problems that I was having with event propagation, and collect() as the kernel.being problematic because of the need for constant re-collect()ing, which is re-executing an expensive tree-walking algorithm.
Back to our favorite example. A glass box publishes an "external" mediation factory and an "internal" mediation factory. External things register an observer on the external mediator. Internal things register an observer on the internal mediator. These mediators are aware at all times of whatever objects they can access, so collect() isn't necessarily an expensive, arbitrarily-complex graph-walk; the edges of the graph are pre-defined, mediators aren't constructed on the fly, and there is some structural notion of containment so that you can iterate the items that your mediator presents as available without worrying about random changes.
The collect() interface remains available for when it's convenient, such as automatically locating targets and tools for actions, but we lessen the focus on it so that actors can also be stateful observers instead of simply making periodic requests of the model. Now all I have to do is think of names for the methods involved.
I hope that there is at least one person in the world who understands what all of those words that I just typed mean, in that order that I typed them.
Posts
2 comments:
Yes.
You know what this reminds me of? BSP trees.
The actual mechanics are a lot different of course, but it's the same motivation: you have a complicated data structure and you want to efficiently determine what's reachable from your current location. So you build what's essentially an index: in a 3D map, it's a binary space partition tree: here it's mediators.
The analogy breaks down, of course. BSPs are only efficient for static geometry; this approach should be decent even if stuff is moving, despite _some_ extra cost.
It vaguely makes sense...but I would love to see pseudo-code
Post a Comment