Add a formatter for a proper OO model

I’m using PlantUML and this great parser to describe my Typescript classes.

Could we imagine an output being a ts/js object that contains the relationships between the class objects ?

Instead of a list of nodes and edges I would like to have an object I can traverse and only contains OOP concepts (not display concepts like visibility or links).

I’m thinking of something a bit like this:

const model = {
  nodes: [{
    name: "MyClass",
    type: "class",
    members: [
      {
        name: "create",
        type: "method",
        isStatic: true,
        isAbstract: false,
        visibility: "public",
        arguments: [{
          type: "Int", // could also be a reference to a class/interface node
          name: "age"
        }],
        returnType: {
          name: "MyClass",
          // ... reference to the MyClass node
        }
      }
    ],
    extends: [ 
      // direct reference to another class node
    ],
    implements: [
      // direct reference to an interface node
    ]
  }]
}

(The direct references would cause circularity which would prevent serialisation but that is not the point)

Would this type of formatter find a place in plantuml-parser ?

[paduc]

Ok I get it ! No loss of information between the PlantUML input and the parser output.

You’re right, I’ll be handling the structure in my higher-level formatter.

[Enteee]

There is one aspect which might have its place in the plantuml-parser representation though. When the PlantUML allows two syntax for a type of relationship, shouldn’t the representation express that relationship in a single manner ? For example, « A extends B » can be expressed by « class A extends B » or « B <|— A ». Shouldn’t both these syntax return exactly the same output ?

When #40 is implemented: class A extends B will be expressed as attribute of A whereas A --|> B will have the effect that there will be a separate relation object in the AST. Which is - in my opinion - correct. Even if the two notation are mostly used to express a is-a - relationship, the AST should reflect them differently. Following a few points why I think this is the correct thing to do:

• A formatter should be able to distinguish between A --|> B and class A extend B if needed.
• A --|> B is valid syntax in a component diagram, but component A extend B is not.
• Inheritance expressed using A --|> B can appear anywhere in the diagram (even before the class declaration). Keeping track of this state in the parser will make the parser very hard to maintain.

I would say, If you need --|> expressed as attribute on the class, this should be easy enough to do in your customer formatter. Putting this inside the parser will be lots of hassle for almost no gain.