Typedef discussion (was: Comments on M3)

[dslmeinte]

• https://github.com/LIonWeb-org/organization/blob/84aaed81cef937c7fb72dadb9c9da8cdb1b22d0a/lioncore/metametamodel.puml#L19 : implements FeatureContainer is not necessary because Annotation extends AbstractConcept which does the same.
• https://github.com/LIonWeb-org/organization/blob/84aaed81cef937c7fb72dadb9c9da8cdb1b22d0a/lioncore/metametamodel.puml#L93 : Shouldn't this be PrimitiveType "1" o-- "*" Typedef: constraints?
• I don't understand the cardinalities of Reference "1" -- "*" Reference: specializes and Containment "1" -- "*" Containment: specializes: shouldn't these be "*" -- "0..1"? A Reference/Containment can optionally specialize one other, but the target could be specialized by any number.

[ftomassetti]

Regarding the first point: you are right. Actually, both interfaces are redundant, and I have removed them

For point 2, I thought that Typedef should not extend PrimitiveType but refers to it: a Typedef would be a Datatype created by providing an alias to a PrimitiveType (they are built-in) and optionally constraining it. It would not be per se a PrimitiveType.

For the cardinalities, I always get confused. What I wanted to state is that each Typedef refers to exactly one PrimitiveType, but each PrimitiveType can be referred by multiple Typedef (or none). To express that, should I invert the cardinalities? If you can confirm that I will invert them (or you can send a PR or do the change directly, as you prefer). Regarding the extension vs reference, perhaps we should clarify that at the next discussion. What do you think?

Cardinalities also apply to point 3. You are right that we should allow the case in which a Containment or a Reference do not specialize anything. Again I may have inverted the cardinalities. Can you confirm this is the case? If so, should I do the change or do you prefer to write a PR or just change the code?

[dslmeinte]

My understanding of <entity1> <card1> -- <card2> <entity2>: <prop> is as follows:

• There's a relation between and with name .
• From (an instance of) you can navigate to a number of 's indicated by .
• From (an instance of) you can navigate to a number of 's indicated by .

So, the “from”-cardinality is at the other end of the arrow.

[dslmeinte]

I'll update my code somewhere later today, so I can check your proposals.

[dslmeinte]

I can make a suggestion through a PR, which would be what the TS code generates. As part of that, I'd suggest to sort the declarations in alphabetic order (with objects first, and then relations). That makes things easily diffable, without having to parse PlantUML and perform a tree-based diff. Is that alright with you?

[ftomassetti]

Yes, that sounds great. Thank you!

[dslmeinte]

Also found the following:

• NamespacedEntity can't be a ConceptInterface because it has the non-derived feature simpleName.
• Likewise for FeaturesContainer with the containment features. FeaturesContainer could be folded into AbstractConcept without problems, I think.

[dslmeinte]

See PR #21

[dslmeinte]

I also worked on the TS implementation, including some constraints checking: https://github.com/LIonWeb-org/lioncore-typescript/tree/feature/m3

[enikao]

If we kept the name FeaturesContainer, the confusion between AbstractConcept and Concept { abstract: boolean } would be resolved. In other words: How about renaming AbstractConcept to FeaturesContainer?

[dslmeinte]

@enikao That's a good idea. I'm trying to think of a better name than the slightly unimpressive “container”, though, but for now (=as long as we didn't release this in any “offical” way) we can stick with it.

[dslmeinte]

What about renaming Typedef to TypeDefinition? It's the only shortened name so far...

[ftomassetti]

+1 for renaming AbstractConcept in something else, but don't we need a common ancestor to both InterfaceConcept and Concept but not Annotation?

[dslmeinte]

Because an Annotation should not be the target of an Annotation? In general, I prefer to use constraints for that (rather than having an “extra” type), but I'm curious what that alternative would look like.

[enikao]

What about renaming Typedef to TypeDefinition? It's the only shortened name so far...

We should get rid of this inconsistency. I'm not sure about TypeDefinition: If I hear Typedef, I have a concrete idea what we're talking about. TypeDefinition could also be a common supertype of Class / Enum / Record (using Java lingo).

In C11 Standard (section 6.7.8) they are called Type definition, though.

The closest thing in MPS is ConstrainedDataTypeDeclaration, which IMHO points in the right direction.

[dslmeinte]

At the moment, Typedef has no semantics yet, so I'm not quite sure which way to go, or even if we already should have it in. We could just remove it for now...

[enikao]

At the moment, Typedef has no semantics yet

I think we had a good purpose for them: The compromise between "we're specifying a protocol, so we need to serialize everything" and "I want to express things like Date or Point in a sensible way that also fits each platform". So a typedef solves the serialization part by referring to one of the primitive types, the express part by being a first-class citizen, and the platform-specific part by annotations like

@Implementation(Java, "java.util.Date")
@Implementation(Typescript, "http://no.idea/how:this.works.in.ts")
typedef Date: JSON

[dslmeinte]

Let's put that in the GDoc. Phrased like this SerializationHint is more to the point as a name, though.

[ftomassetti]

I think the original comments from @dslmeinte have been addressed by his PR. Later we discussed about typedefs. Did we reach a conclusion about that? Is there any other topic left open in this issue?

[dslmeinte]

Yes: my original comments are addressed.

As for the Typedef-discussion: the M3 GDoc mentions “TODO: add an entry for Typedef”, so I guess that still stands ;)

[ftomassetti]

I will rename the issue, so that it will be easier to notice what topic is left to discuss