Have a default way to manage derived properties of nodes

[enikao]

Examples:

• Type of the node
• Interpretation result

Option A: Represented as DerivedFeature

Pro:

• No structural changes in M3

Con:

• Might need support of DerivedProperty and native custom types in M3, e.g. if interpretation result can be any Java Object.
• Calculation of derived property might involve lots of scoping, re-calculation based on events, etc.
  We don't want these aspects to creep into M3.

Option B: Represent as separate aspect outside M3

Pro:

• Don't inflate M3
• Separation of concerns

Con:

• Harder to access

Decision: Option B

Rationale:

• too invasive for M3
• easier to postpone
• we don't understand the issue well enough yet

[markusvoelter]

I actually don't remember that we decided to keep this outside of M3. I can live with it, and maybe I was asleep for a moment :-)

[dslmeinte]

I'd prefer to keep these kind of functions that work across a whole model separate from just the metamodel.

[ftomassetti]

I wil copy here something I shared on Slack as I think it is relevant to this discussion.

Let's assume that KRNode is an implementation of the Node interface that we have yet to define as part of M1. In this case KRNode stands for Kotlin Reflective Node, because it has an implementation of getConcept that derives the concept from the Kotlin class definition.

This is very similar to the approach we have been using in Kolasu (our library for ASTs) for years. We defined derived properties like that:

This approach is very convenient for us, because there is no generation involved. We do not need to define the metamodel and generate Kotlin code from it, we define instead the Kotlin code and derive the metamodel from it. In this case defining derived properties is very easy: we just do that in Kotlin. The problem is that it is not portable across platforms.

[dslmeinte]

I could even see us not defining derived properties in the M2 at all. Instead, we'd define those on top of an M2. That would also be convenient as a separate model query language. With derived properties, some derivations live in the M2, while others live outside of it.

[ftomassetti]

What I remember is that we did not want to have the logic to calculate the derived values in the metamodel, but I am not sure if we decided not to have even the declaration of derived feature (with implementation left outside).

I am fine with both having just the declaration or leaving them outside of the metamodel

[dslmeinte]

Not enabling to define derived features in the M2 is a personal preference of mine. I'm not sure whether it's shared.

[enikao]

Is this about derived models, not only properties? Then we should add derived tag.

[dslmeinte]

I think this particular should just fold into the bigger work for derived models, without a need for this small context. So, let's close it.

[enikao]

Will be discussed as part of #181.

[joswarmer]

Should close this