Extending OB metagraphs
Colin Putney
cputney at wiresong.ca
Sat May 5 19:48:52 UTC 2007
On May 5, 2007, at 11:07 AM, Damien Cassou wrote:
> Is it clearer now ? The package DynamicProtocols has to modify the
> meta graph. I can do it when the meta graph is constructed in
> OBCodeBrowser>>addTo* but this would be an override. My current
> solution is to reimplement #addTo: in the subclasses I want:
> OBSystemBrowser and OBHierarchyBrowser.
>
Yes, this is hard.
A lot of my recent work with OB has been aimed at improving the
extensibility of browsers built with OB. Commands, for example, are
better than Actions were, mainly because new ones can be added
without changing any existing code. It's not hard, because code for
building a list can be extended just by building another list and
concatenating them.
On the other hand, I haven't had any ideas about making the
construction of the metagraph extensible. The original idea with OB
was to have a registry of metagraphs that could be modified in place,
kind of like the SystemDictionary. If you modified the metagraph, the
behavior of browsers would change. That turned out to be tricky to
manage, so we moved to a system where each different type of browser
has it's own subclass, and builds the metagraph when the browser is
opened. That's been better, but it doesn't get around the deeper
problem of extensible graph construction.
So, here's the problem. Perhaps someone here has an insight that can
help solve it. (For more detail, read the OB paper that was recently
announced here.)
The behavior of each browser is governed by a metagraph. A metagraph
is a DG, consisting of nodes connected by directed edges. The graph
can have cycles, and they frequently do. Both nodes and edges can
have additional attributes attached to them. We need to be able to
programmatically build a metagraph in such a way that the code used
to build it can be dynamically discovered, can reside in several
different packages, can affect the structure of the graph without
overriding code in another package, and be composed without risk of
creating invalid graphs.
Ideas? Perhaps this is a well-understood problem, and I'm just
ignorant of the solution.
Colin
More information about the Squeak-dev
mailing list
|