In UML, a constructor operation is supposed to return the newly constructed object, and this is presumed in the current mapping for instance creation expressions using a constructor operation. When a constructor is mapped from Alf, the return parameter is added automatically and the returning of the object is handled in the constructor body mapping. However, when a constructor is added to a class using a graphical UML tool, it is awkward to have to include an explicit return parameter, and it doesn't add any value to do so, anyway. Further, the expectation from constructors in programming languages is that they do not have an explicit return value, so it is often left out in the model, too -- which would cause an error with the current mapping if such a constructor so modeled was used in an Alf instance creation expression.
Since the value returned from the constructor should always be the newly constructed object anyway, it would be better if the mapping for the instance creation expression used the result of the create object action as the result value for the expression and simply ignored the value returned from the constructor (if any). In this way, it would not be necessary to require that a constructor from an external model be have a return value (but it would still work if the constructor had one, as long as the returned value was the constructed object, as expected).
seidewitz
commented
7 years ago
In UML, a constructor operation is supposed to return the newly constructed object, and this is presumed in the current mapping for instance creation expressions using a constructor operation. When a constructor is mapped from Alf, the return parameter is added automatically and the returning of the object is handled in the constructor body mapping. However, when a constructor is added to a class using a graphical UML tool, it is awkward to have to include an explicit return parameter, and it doesn't add any value to do so, anyway. Further, the expectation from constructors in programming languages is that they do not have an explicit return value, so it is often left out in the model, too -- which would cause an error with the current mapping if such a constructor so modeled was used in an Alf instance creation expression.
Since the value returned from the constructor should always be the newly constructed object anyway, it would be better if the mapping for the instance creation expression used the result of the create object action as the result value for the expression and simply ignored the value returned from the constructor (if any). In this way, it would not be necessary to require that a constructor from an external model be have a return value (but it would still work if the constructor had one, as long as the returned value was the constructed object, as expected).