mermaid-js / mermaid

Generation of diagrams like flowcharts or sequence diagrams from text in a similar manner as markdown
https://mermaid.js.org
MIT License
71.78k stars 6.51k forks source link

a generic class with different type arguments is rendered as the same class symbol #4762

Open ksilverwall opened 1 year ago

ksilverwall commented 1 year ago

Description

INPUT a generic class with different type arguments, ex class Shape~T1~ and class Shape~T2~

classDiagram
  class Shape~T1~
  class Shape~T2~

rendered as a same object

classDiagram
  class Shape~T1~
  class Shape~T2~

Generally, classes with different types should be interpreted as different types.

Steps to reproduce

render this code

classDiagram
  class Shape~T1~
  class Shape~T2~

Screenshots

No response

Code Sample

No response

Setup

Suggested Solutions

No response

Additional Context

I will discuss specifically how it can be useful. I want to write diagram like this. (_xxx_ means Generics)

classDiagram
  class CompositorHandler {
    RequestQueue: Queue_CompositorMessage_
  }
  class ConverterHandler {
    MainQueue: Queue_ConverterMessage_
    SubQueue: Queue_ConverterMessage_
  }
  class Queue_T_ {
    <<interface>>
    Pop(): T, error
        Push(): error
  }
  class Queue_CompositorMessage_ {
    <<interface>>
    Pop(): T, error
        Push(): error
  }
  class Queue_ConverterMessage_ {
    <<interface>>
    Pop(): T, error
        Push(): error
  }
  class CompositorSQS
  class ConverterSQS

  Queue_T_ <|-- Queue_CompositorMessage_: T=CompositorMessage
  Queue_T_ <|-- Queue_ConverterMessage_: T=ConverterMessage
  CompositorHandler *-- Queue_CompositorMessage_
  ConverterHandler *-- Queue_ConverterMessage_
  Queue_CompositorMessage_ <|-- CompositorSQS
  Queue_ConverterMessage_ <|-- ConverterSQS
tomperr commented 1 year ago

This is an interesting feature. However, this might change how we identify classes with generics. For example, with your example, to add a relationship we would do

classDiagram
    class Shape~T1~
    class Shape~T2~
    Shape~T1~ --> Shape~T2~

Currently, as we handle classes with generics that do not have the same classnames, we do it that way

classDiagram
    class A~T1~
    class B~T2~
    A --> B

In the relationship, we identify the classes by their classname only, not by their classname + their type.

So, to make this feature possible, we must force the user to specify the classnames + the types in relationship (as in the first example), OR we must accept both : with types if needed (like in the first example), without if not (like in the second example). The first option would be a breaking change.

sidharthv96 commented 1 year ago

The first option would be a breaking change.

Which we cannot have in syntax. So we should go with the 2nd option.

jgreywolf commented 1 year ago

I will look into this, as I am going through a bunch of stuff in class diagrams right now. But I am concerned that the solution put in place to handle class generics many years ago might make this a little difficult...