Before I wrote the mail about registries (which indeed is a solution for 
Smalltalk browser, with unknown power for generalization), I though of 
the following more complex direction:

*******
There are two problems here - one is specifying graphs and extensions to 
graphs. The second is that this should be done cooperatively by a set of 
packages, each of which can be updated independently.

How about the following approach:
1. Maintain a registry of named graph construction specs.
2. Each spec is a sequence of graph transformers, the first of which 
simply constructs the initial graph.
3. Graph nodes have labels giving their logical function, so that 
transformations don't depend too much on the structure of the graph to 
find the part to affect, and thus don't break too often.
4. To add a variant browser, search for the spec you want to start from, 
then modify it (or probably a copy) by replacing or concatenating steps. 
The result can be either added as another variation, or replace the 
previous.

As a start, the transformers can simply be code that searches for a 
named node, and does stuff to it. For example, Damien would create a 
method that searches for node labeled #SecondaryCategories and adds 
something to it. In general, there's a theory of graph grammars and 
graph transformations that might be useful, at least as a source of 
ideas for how the transformations should work. The RB actually 
implements such a grammar for trees, and uses it to express some 
refactorings more easily. Not sure if we need this at the moment.

Thus we can reuse transforms, and we can reuse the sequences. The tricky 
part is the cooperation - what happens when someone updates a package. 
Thus I'd propose a model in which each package can only add variants to 
the tree, not modify those of other packages. When a variant is changed, 
those created based on it are notified and can update themselves (or not).

*******


I eventually sent the other mail because its much simpler, solves our 
current issues, and might generalize better than we think now. And a 
solution as I outlined above would definitely be complex to use for all 
extenders.


Daniel Vainsencher



Colin Putney wrote:

>
> On May 5, 2007, at 3:15 PM, Damien Cassou wrote:
>
>
>> Firstly, I think OB needs a graph entity This graph would let methods
>> access any node using its name with just a simple call
>> (OBGraph>>getNodeNamed:). It should be possible to remove edges too I
>> think.
>>
>> Then, OB has to make this variable directly accessible to all class
>> side methods. The graph might be stored in a class variable.
>>
>> When a new browser is created, all methods whose name starts with
>> #buildGraph are executed. Those methods have access to the graph and
>> to all its nodes. So, I think they can do whatever they want with the
>> graph.
>>
>> Isn't that enough to have a dynamic graph?
>>
>
> I suppose it's better than what we have now, but only a little, I 
> think. The main problem would be one of ordering and composition. If 
> you're doing something like adding dynamic protocols to the graph, the 
> code to do that has to run after the main graph has been built, and 
> before  code that does other things to existing edges and nodes. There 
> would have to be a fairly complex, protocol for orchestrating all of 
> that, and even then, I think it would be brittle.
>
> Colin
>
>