Add a formatter for a proper OO model
See original GitHub issueI’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
?
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
Creating a Formatter Extension - Visual Studio Code
Best practices for creating a Visual Studio Code formatter extension.
Read more >Design of class hierarchy for a object formatter API forces ...
So I made the Formatter be the base class. But with my current design, all derivatives of this base class would need to...
Read more >Keeping data and formatting separate in object oriented design
I am creating a program where I have objects called "hierarchies", which is little more than a list of lists with strings (...
Read more >Build seven good object-oriented habits in PHP - IBM Developer
Use pattern names, like Factory, Singleton, and Facade. Stub out large portions of the model, then start adding implementation. Conclusion.
Read more >Format String in Java with printf(), format ... - Stack Abuse
In this tutorial, we'll be formatting Strings in Java using printf(), System.format(), String.format(), the Formatter and MessageFormat ...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.
When #40 is implemented:
class A extends B
will be expressed as attribute ofA
whereasA --|> 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 --|> B
andclass A extend B
if needed.A --|> B
is valid syntax in a component diagram, butcomponent A extend B
is not.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.