Usage of implicit type casts

[georghinkel]

I just came across the name evaluation contained in the Families2Persons example. The expression there is the following:

Evaluate ComputeFullName {
  field fullName
  expression member.firstName + ' ' + member.eContainer.lastName
  target SplitByGender
}

The first very bad thing here is obviously that eContaineris something very specific to EMF - which is not suitable for the TTC that should be somewhat independent of EMF.

The second big obstacle here is that it is absolutely not clear what the type of the eContainer could be. This is an obstacle for any strongly-typed approach. So I would like to ask you to add an optional field to this expression type that specifies the type of the expression.

[agarciadom]

Yes, I could've just used container, but I chose eContainer as the semantics would be familiar to anyone that used EMF. For a production version I'd rename it to something EMF-independent, of course :-).

Could you provide a concrete example of how that optional field would look like? Doesn't NMF have a root interface/class for all objects, with something for getting attribute values by name?

[georghinkel]

A concrete syntax for the example could look as follows:

Evaluate ComputeFullName {
  field fullName
  expression member.firstName + ' ' + (member.eContainer as Families!Member).lastName
  target SplitByGender
}

In the abstract syntax, this would mean an optional type field for an expression where one could override the type in which the expression is retrieved. Alternatively, you could add an explicit cast as a primitive type. The latter I think is more elegant while the former has the advantage that it can be realized without breaking the description. So, if there is still some room to modify the description (noting that there is also a Cast primitive that could be supported), I guess it would be cleaner to just add an expression primitive here.

Otherwise, I am not sure in which context this is used in the example models, but my initial proposition is actually not accurate, in some cases you can actually know what the type of the container of a Member element is, because there is exactly one class that has a containment relation to it. So, perhaps this can be done for all test cases, but nevertheless, an explicicit type information would be useful (and the interpreter implementation is super simple because it doesnt have to do anything).

[agarciadom]

I see, this makes perfect sense and we'd definitely support this beyond TTC. However, I'm afraid that this far into TTC we can't really change the syntax + case studies, however :-(.

A quick check shows that eContainer is only needed for Families2Persons within TTC, and in there there's only one possible type (Family). Perhaps you could simply add this bit of analysis within your engine and just fail if there were multiple potential container types for a usage of eContainer? You only need to do a pass over the .ecore file and precompute container types.

[agarciadom]

Nevertheless, if you feel you wouldn't be able to complete your solution otherwise, I'd suggest adding an additional attribute yourself to the XMI representation and explaining this limitation about the notation in your TTC presentation :-). Criticism of the notation itself is welcome!