Which parts of a link can be specialized?

[enikao]

AbstractConcepts can specialize the type of a Link of all transitively extended AbstractConcepts.

• Can a specialization change the link's cardinality?
• Can a specialization change the link's name?

Specializing cardinality

Pro:

• consistent if we can also change type and name

Con:

• Few use cases
• Supporting changes between singular and multi-valued containments unfeasible

Specializing name

Pro:

• Closer alignment to domain ("NeedleTree.needles" vs. "NeedleTree.greenTreeThings")

Con:

• Interferes with regular OO method overriding (Java class NeedleTree defines method getNeedles and inherits getGreenTreeThings)

Example A: Only change type

classDiagram
Tree --> "0..*" GreenTreeThing: greenThings
<<abstract>> GreenTreeThing
Tree <|-- NeedleTree
GreenTreeThing <|-- Needle
NeedleTree --> Needle: greenThings specialized

Loading

Example B: Change type, cardinality, name

classDiagram
Tree --> "0..*" GreenTreeThing: greenThings
<<abstract>> GreenTreeThing
Tree <|-- NeedleTree
GreenTreeThing <|-- Needle
NeedleTree --> "1..*" Needle: needles specializes greenThings

Loading

[slisson]

We should collect use cases and try to find alternatives. From a typesystem perspective the specialized links in MPS are unsound.

[enikao]

@slisson Could you explain the typesystem issue with specialized links?

[slisson]

node<NeedleTree> needleTree = new node<NeedleTree>()
node<Tree> tree = needleTree
tree.greenThings.add(new node<GreenTreeThing>())
node<Needle> needle = needleTree.greenThings.last

The variable needle actually references a node<GreenTreeThing>, but because of the specialization the type system doesn't show an error. A sound type system has to prevent write access to Tree.greenThing which means specialization can only be allowed if Tree.greenThing knows that it can be specialized. In Java this would be done with generics and the java type system does prevent write access in such cases.

[enikao]

Thanks for the example.

Possible solution: Assuming DerivedFeatures are read-only, we could allow only them to be specialized.
(DerivedFeature would not be that great of a name then, though.)

[markusvoelter]

I would suggest to not have specialized Links and handle it -- as you suggest, @enikao -- through derived features, if at all. And yes, derived features are always readonly.

[dslmeinte]

I agree to not have Link specializations at all. We pretty soon venture into territory that should be covered by an actual type system and constraints defined on top of a particular metamodel.

[ftomassetti]

+1 for not having specialized links

[markusvoelter]

Decision: No structural specialisation (of links and stuff) because

• let's keep things simple
• can be emulated with derived features + constraint
• even MPS wants to get rid of it :-)