You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A variant of the name-clash problem as described in section 3.3. Also related to #97.
In a concept, can we define a feature with the same name as a feature in extended super-concept or an implemented interface?
Example:
classDiagram
class A {
string f
}
class B {
string f
}
class C {
int f
}
class D
class D_Child
D *-- D_Child: f
class E
class E_Target
E o-- E_Target: f
A <|-- B
A <|-- C
A <|-- D
A <|-- E
Loading
We've already decided to disallow specializations in #8.
Technically, we can support such features, as we identify them by id or key (and don't really care about the name).
However, having multiple features with the same name is confusing. We allow it for inheritance because we might not be able to change the implemented interfaces. We can always change the element itself.
The rationale of this decision is not very strong. After some experience, we might revise it.
A variant of the name-clash problem as described in section 3.3. Also related to #97.
In a concept, can we define a feature with the same name as a feature in extended super-concept or an implemented interface?
Example:
classDiagram class A { string f } class B { string f } class C { int f } class D class D_Child D *-- D_Child: f class E class E_Target E o-- E_Target: f A <|-- B A <|-- C A <|-- D A <|-- EWe've already decided to disallow specializations in #8.
Technically, we can support such features, as we identify them by id or key (and don't really care about the name).
However, having multiple features with the same name is confusing. We allow it for inheritance because we might not be able to change the implemented interfaces. We can always change the element itself.
The rationale of this decision is not very strong. After some experience, we might revise it.