QVT12 — Inconsistent description about constructor names

Problem:

Specification first says in the Constructor concept description:

"The name of the constructor is usually the name of the class to be
instantiated. However this is not mandatory. Giving distinct names allows having more than one constructor."

Later on in the Constructor notation:

"The name of the constructor is necessarily the name of the context type"

This is inconsistent.

Discussion:
Indeed, the notation section statement seems to be correct since:
1. Looks like other programming languages, like Java.
2. More importantly, the instantiation expression would not be so obvious when constructing new objects, and would required to be changed.

Example:

If we have the following constructors:

constructor MyClass::MyClassConstructor(name : String)

constructor MyClass::MyClass(name : String)

How can the instantiation expression refer the different constructor ?

• new MyClass("abc")
• new MyClassConstructor("abc")
• new MyClass::Constructor("abc")

The referred class in a InstantiationExp would not be enough. Changing instantiation expression to provide different name constructor doesn't seem sensible.

Proposed solution:

In section 8.2.1.13

Replace:

"A constructor does not declare result parameters. The name of the constructor is usually the name of the class to be
instantiated. However this is not mandatory. Giving distinct names allows having more than one constructor."

by

"A constructor does not declare result parameters and its name must be the name of the class to be instantiated."

This was discussed on https://bugs.eclipse.org/bugs/show_bug.cgi?id=421621.
Unless we abandon constructor diversity completely, the current AS imposes a needless
implementation difficulty by requiring dynamic resolution of a statically known constructor. This can be
avoided by augmenting InstantiationExp.instantiatedClass with
InstantiationExp.initializationOperation , which can refer to any statically determined constructor. We
can therefore relax the contradictory restrictions on constructor name spelling.
Unfortunately Constructor is not available in ImperativeOCL. Promoting Constructor to ImperativeOCL
would appear easy, unfortunately its superclass ImperativeOperation is also not available. Promoting
ImperativeOperation requires … too hard. So we must instead introduce InstantiationExp.
initializationOperation and redefine it in ObjectExp.