Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support parameterized class in classDiagram #5623

Open
benfortuna opened this issue Jul 5, 2024 · 2 comments
Open

Support parameterized class in classDiagram #5623

benfortuna opened this issue Jul 5, 2024 · 2 comments
Labels
Status: Triage Needs to be verified, categorized, etc Type: Enhancement New feature or request

Comments

@benfortuna
Copy link

Proposal

UML provides a syntax for type binding via parameterized class:

http://etutorials.org/Programming/UML/Chapter+6.+Class+Diagrams+Advanced+Concepts/Parameterized+Class/

This proposal seeks to be able to add a label on a relationship using the following syntax:

ClassA~T~ <|-- ClassB: <<bind>>T::String

In this example the type String is bound to generic type T for implementation ClassB.

Currently this is a syntax error due to not supporting <<>> and :: in labels.

Example

ClassA~T~ <|-- ClassB: <<bind>>T::String

Screenshots

No response

@benfortuna benfortuna added Status: Triage Needs to be verified, categorized, etc Type: Enhancement New feature or request labels Jul 5, 2024
@jgreywolf
Copy link
Contributor

There are a couple of issues here:

  • << >> is already used as syntax for associations.
  • < and > are problematic by themselves due to potential of script injection, which is why we ended up using ~ ~ to signify generics.
  • :: is already being used as shorthand to associate a node with a class

From the link you provided there are two ways that this can be displayed, one is similar to what we already support, such as: ClassA<ClassB>, displayed without any members
06fig19

I am thinking that since this is an alternative method for displaying parameterized classes the priority of adding this is fairly low, but that could be changed based on requests ;)

@benfortuna
Copy link
Author

benfortuna commented Aug 27, 2024

Ok.

So I guess what you are saying is in defining a bound implementation (i.e. ClassB<String>) it is implying that String is substituted for T defined in members of the superclass/interface (ClassA)?

i.e. ClassA~T~ <|-- ClassB~String~

Not ideal, but I accept there are challenges in supporting the additional syntax. Thanks for following up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Triage Needs to be verified, categorized, etc Type: Enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants