Hi,
The issue is related to when you use the RtCppProperties profile to provide "type modifier" to a parameter of a protocol message, e.g. making it a pointer to the specified type.
This is something that is not supported in legacy models, and I am really not sure if, and how, we are going to support this in Papyrus-RT. I actually had a discussion with Remi about this when I showed him how it works when defining protocol messages in legacy tooling. Remi also brought up the aspect of providing multiplicity for a parameter of a protocol message which is not supported either in legacy tooling (well, you can specify multiplicity if you manipulate the low level UML model, but the code generator ignores it).
First of all we need to consider the send-by-value semantics of protocol message sending and the fact that in legacy models protocol messages only had one parameter. Or actually they conceptually had a protocol message which was typed with one single type. The parameter was something that came along with when UML-RT became based on UML 2 and it is only "hidden" internally. In earlier legacy tooling the UML-RT meta-model did not even have a notion of a parameter for a protocol message.
Anyway, back to the send-by-value semantics. When sending a protocol message a copy is made of the data to ensure the send-by-value semantics. For primitive types a simple copy is made, and for the case when the protocol message is typed by a used defined data class, the copy constructor is used to copy the data. And here the aspect of type descriptors come into play.
The user then have the possibility of overriding the type descriptor, by for example providing its own copy function body to alter the behavior of the default copy constructor, e.g. if a deep-copy or a shallow-copy (or something in between) shall be made or not. Since the type descriptor information is related to the class itself and also you can override type descriptor and type modifiers for the individual attributes of the class, i.e. it is properties of the RtCppProperties profile and stereotypes applied on the class and its attributes.
So traditionally, you have always created a class with attributes to handle more complex types, and you have used the type descriptors for the class and it attributes to control how the copying during the send actually have been performed, e.g. if you want to control if its a shallow or deep copy that is made.
But now we are entering uncharted territory, with the introduction of multiple parameters, and possibly also providing type modifiers already within the scope of the protocol message itself.
To my knowledge, we do not have any type descriptor(s) generated at the scope of a protocol message and its parameters. Yes, there are RtCppProperties related to how parameters for ordinary operations owned by capsules and classes shall be generated in the resulting C++ code.
But the parameters of a protocol message is *not* the same as parameters of an ordinary operation. I would argue that the parameters of protocol message should be much more constrained than the parameters of an ordinary operation, e.g. related to that they cannot have type modifiers, cannot have multiplicity, can only have direction in, and so on. It might be that we lack some constraints in the UML-RT profile to clarify this.
On the other hand, *if* we shall support type modifiers for the parameters of a protocol message, then I have a strong feeling that we need to look into the aspect of type descriptors and ensuring that the end-user can provide its own type descriptor information for the protocol message and its parameters. This would then be another set of properties in the RtCppProperties profile that is only applicable for parameters of a protocol message since they will not make sense for parameters for an ordinary operation.
Based on this, I would actually propose that we (at least initially) do not support parameters of a protocol message to be typed by anything anything else than a "base type", i.e. either a primitive type or a user defined data class. We shall not support "creating a new type on the fly" by specifying a type modifier saying that the type is a pointer to the specified type (as is the case that Ernesto raises in the Bugzilla and the Gerrit change).
If the user has a need for more complex types, e.g. pointers, arrays and so on, then the pattern used in legacy models is the way to go, i.e. create an additional user defined class with attributes. Then the user can user the RtCppProperties for the class to specify the copy semantics, type modifiers and so on.
Take the following classic example: The user want to send a dynamically sized array of elements. The user then creates data class with two attributes, one indicating the size of the array and attribute which is pointer to the type of elements in the array. For the pointer attribute the user can provide a "numElementsFunctionBody" which basically returns the value of the first attribute. Based on the type descriptor information for this class, a deep copy can now be made where only the current number of elements in the array is copied.
How shall we handle this case if we made these two attributes to be directly as two parameters of the protocol message? How do we ensure that the number of elements to be copied for the second parameter is based on the value of the first parameter? In which "context" can we provide the user a way of defining that?
From a meta-model perspective a protocol message only have a name and a type. Then the specified type's type descriptor is used for the copy operation (avoiding the aspect that a new type is created "on the fly" if we allow type modifiers to be specified for the parameter for which we really do not know and can control how it is being copied).
Any comments?
/Peter Cigéhn
