Seems to me that extending browsers by adding commands (such as "find 
Trait" in addition to "find class") and "fake" elements like  
DynamicCategories provide, can be done by having registries for them 
like the Services framework provides for dynamic menus and Browsers 
(don't know if Services can be reused, or we need to apply some of the 
same patterns again).


Then the standard browsers can simply add all the relevant extras 
dynamically, and maybe allow a user to hide some of them.


This dodges the more general question of making the actual graphs 
extensible. I had an idea about this involving graph rewrite rules, but 
the solution above sounds simpler, and might work (at least for the 
current cases), so...


Daniel

Colin Putney wrote:

> 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
>
>