Potential language extension for graph object classes - motivation, design

It’s not so important. The meaningful problems are bugs in spline routing, orthogonal edge routing, the “trouble in init_rank” that would not die, lack of object classes in the graph language, and one or two outstanding CERT advisories. That weird bug with ports on record nodes being flipped in certain left-to-right layouts Incrementally stable layout in dotgen, Can gvedit make the jump to QT6. New algorithms that could help with untangling hairballs. These are interesting topics.

Stephen, could you elaborate on “lack of object classes in the graph language”. What kind of classes? Do you mean like style attribute classes (like CSS classes) that are shorthand for a set of attributes?

Agree it’s not that important to reduce the number of mallocs used.

The idea was to someday support classes, like

    node myclass [shape=box, style=filled, fillcolor=lightblue]
    node myotherclass [fillcolor=palegreen,fontname=Helvetica]
    somenode [myclass, myotherclass]

There would need to be a dict of dicts for each graph object type in each graph/subgraph. There would need to be functions for operating on them.

Some thought would have to be given to how to write the graphs correctly.

It might be easier to at first consider classes to be immutable after they’re defined.

I like that, @scnorth. That is exactly what I do with Vithanco. I create Node Types, and I even define which type can be connected to which other Node Types, hence I create a Meta model for my graph.

I found it very useful to have the Node Type name in the node, I use that in most meta models. Here an example from the Benefit Breakdown Structure (Domain)

And yes, I use Graphviz for the layout, I just draw the nodes myself.

I think that class syntax could really help for the usecase of technical graphs checked in to documentation. Some of it we can achieve with CSS on generated SVG but not all. We have the “class” attribute that we might want to reuse to avoid users naming their own attributes that might conflict with future attributes?

I really liked the idea of class syntax. Did you consider it any further?