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