Issue 19021: Inconsistent description about constructor names (qvt-rtf) Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody) Nature: Clarification Severity: Minor Summary: 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) { name := name } constructor MyClass::MyClass(name : String) { name := name + "v2" } 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." Resolution: 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. Revised Text: In 8.2.1.13 Constructor notation change The name of the constructor is necessarily the name of the context type to The name of the constructor is usually the name of the context type In 8.2.1.24 ObjectExp add /initializationOperation : Constructor [0..1] (from InstantiationExp) The constructor that uses the arguments to initialize the object after creation. The constructor may be omitted when implicit construction occurs with no arguments. In 8.2.2.23 InstantiationExp add initializationOperation : Operation [0..1] The initialization operation that uses the arguments to initialize the object after creation. The initialization operation may be omitted when implicit initialization occurs with no arguments. In Figure 8.5 add Operation (from EMOF) unidirectional reference from InstantiationExp to Operation -- forward role initializationOperation [0..1] -- reverse role instantiationExp [*] Actions taken: October 23, 2013: received issue July 15, 2014: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 23 Oct 2013 07:04:53 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Adolfo Sáhez-Barbudo Herrera Employer: The University of York mailFrom: asbh500@york.ac.uk Terms_Agreement: I agree Specification: Meta Object Facility (MOF) 2.0 Query/View/Transformation Section: 8.2.1.13 FormalNumber: 11-01-01 Version: 1.1 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: 90 Title: Inconsistent description about constructor names Nature: Clarification Severity: Minor CODE: 3TMw8 B1: Report Issue Remote Name: wc12.york.ac.uk Remote User: HTTP User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.101 Safari/537.36 Time: 07:04 AM Description: 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) { name := name } constructor MyClass::MyClass(name : String) { name := name + "v2" } 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." X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=VqIaXYGn c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=vxK9YoavaOMA:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=-TEtUPenjcAA:10 a=LzAIKTWX9b8tix6ZZYYA:9 a=6q5qt2vHnn-ioRcY:21 a=wPNLvfGTeEIA:10 a=_W_S_7VecoQA:10 Date: Thu, 30 Jan 2014 11:08:36 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: "qvt-rtf@omg.org" Subject: Issue 19021: Inconsistent description about constructor names. X-Virus-Scanned: amavisd-new at omg.org Hi The proposed resolution currently in ballot 2 In 8.2.2.23 InstantiationExp add referredConstructor : Constructor [0..1] introduces a reference from ImperativeOCL to QVTOperational. There is a simple fix: 1) minimal change: Move Constructor from QVTOperational to ImperativeOCL. 2) coherent change: Move Constructor, ConstructorBody, ObjectExp from QVTOperational to ImperativeOCL. Constructing objects is a kind of useful imperative thing to do, so allowing ImperativeOCL to do this seems sensible. ---- The resolution as ballotted is bad so it is withdrawn from ballot 2. A revised resolution will appear in the ballot 3 preview possibly today, probably tomorrow. Regards Ed Willink X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:message-id:date:from:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ivHjnzR1nRRn8tx5bo5hBo4XC/cu/xGJs+1xXqW8aF0=; b=j/LPC2+ID4wxeorQDBr11DkzMB3Ih6zZM2ErWgdGUfkMzpvY8QUurYKPO/v0AlKN3T XYJfqwiX7/tdEP9Hm1hOtHyXbe1CbNq7LdfQPFklqVbiQnd+PvIfJ7MIF+BFKW0Gkrhc l2GlWs6KLxAq7Jc1RWVjlKsNetd9xA20oUDDCvlslomyGyhqZkZwTPSljr+sfiaI6jwe Amtb4tBoUsLl9OvFwqM1WwK3T5WOGaFaXRDHDvKdoIOTMYW9Z3ekDPRHpCiMj5ADGtp5 L0D2LXF2h8uFdWPaXGxh1MxfrgOKCq3uyzx1ylHIIh4NkmQv9TA9P7jUHLOpgEAycUXw si8A== X-Gm-Message-State: ALoCoQkTmwimKAf7WNf6J73pFYQrbJzzUPJzBJpJ1zpRLvyycyD4Tr9k1K6OEBraZLNrmd+mYGLG X-Received: by 10.194.58.132 with SMTP id r4mr2246109wjq.45.1391102314278; Thu, 30 Jan 2014 09:18:34 -0800 (PST) Sender: Adolfo Sanchez Barbudo Date: Thu, 30 Jan 2014 17:18:29 +0000 From: Adolfo Sáhez-Barbudo Herrera Organization: Open Canarias S.L. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20131118 Thunderbird/17.0.11 To: Ed Willink CC: "qvt-rtf@omg.org" Subject: Re: Issue 19021: Inconsistent description about constructor names. X-Virus-Scanned: amavisd-new at omg.org Leaving aside the always-pedant never-consistent reasoning of a policy related to breaking changes (the AS in this case), I have something to add to your comments. I don't think that ImperativeOCL needs two ways of constructing objects. I'd not move ObjectExp. In QVTOperational, ObjectExp is useful when combined with the result variable of a mapping, for instance. As additional 2cents, and as a non RTF member, I've also had a look just to other resolutions to the issues I submitted (omitting issue 13268, for which I've already given my point): **** Issue 13265 **** Let me throw a couple of questions: - What does "hierarchical scope" of a configuration property mean? - How does this "hierarchical scope" get reflected in the abstract syntax ? - Which is the owner of this configuration property ? a) The transformation ? b) UML::Attribute ? - Which is the qualified name of such a property, for instance, to access its value? a) MyTransformation::MAX_SIZE ? b) UML::Attribute::MAX_SIZE ? c) MyTransformation::UML::Attribute::MAX_SIZE ? [Suggestion: Reconsider the issue suggestion] Regards, Adolfo. -- On 30/01/2014 11:08, Ed Willink wrote: Hi The proposed resolution currently in ballot 2 /In 8.2.2.23 InstantiationExp add// //referredConstructor : Constructor [0..1]/ introduces a reference from ImperativeOCL to QVTOperational. There is a simple fix: 1) minimal change: Move Constructor from QVTOperational to ImperativeOCL. 2) coherent change: Move Constructor, ConstructorBody, ObjectExp from QVTOperational to ImperativeOCL. Constructing objects is a kind of useful imperative thing to do, so allowing ImperativeOCL to do this seems sensible. ---- The resolution as ballotted is bad so it is withdrawn from ballot 2. A revised resolution will appear in the ballot 3 preview possibly today, probably tomorrow. Regards Ed Willink X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=WPfxXxcR c=1 sm=1 tr=0 a=eW53zEZrsyElcQ0NK1QpqA==:117 a=eW53zEZrsyElcQ0NK1QpqA==:17 a=0Bzu9jTXAAAA:8 a=U5aTihw9y_sA:10 a=OrQLSuLXTz4A:10 a=8nJEP1OIZ-IA:10 a=YYzpnO7rAAAA:8 a=34OfzxuFJiQA:10 a=oCcaPWc0AAAA:8 a=jlcgVcSuQN0xnhn2GL4A:9 a=wPNLvfGTeEIA:10 Date: Thu, 30 Jan 2014 19:09:14 +0000 From: Ed Willink User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 To: Adolfo Sáhez-Barbudo Herrera CC: "qvt-rtf@omg.org" Subject: Re: Issue 19021: Inconsistent description about constructor names. X-Virus-Scanned: amavisd-new at omg.org Hi Adolfo You can see from the ballot 3 preview that the Constructor move is not sensible so the ObjectExp move is not sensible either. We have very few comments from FTF members so non-FTF comments are particularly welcome. However you would make life much easier for us if you do not try to piggy-back a completely orthogonal Issue 13265 discussion onto an Issue 19021. And if you want to discuss Issue 13265, you might start by rewriting the original issue to clearly identify an actual problem. Not being representable in the AST or not being parseable with the BNF would be such problem; and we should address them. Regards Ed Willink On 30/01/2014 17:18, Adolfo Sáhez-Barbudo Herrera wrote: Leaving aside the always-pedant never-consistent reasoning of a policy related to breaking changes (the AS in this case), I have something to add to your comments. I don't think that ImperativeOCL needs two ways of constructing objects. I'd not move ObjectExp. In QVTOperational, ObjectExp is useful when combined with the result variable of a mapping, for instance. As additional 2cents, and as a non RTF member, I've also had a look just to other resolutions to the issues I submitted (omitting issue 13268, for which I've already given my point): **** Issue 13265 **** Let me throw a couple of questions: - What does "hierarchical scope" of a configuration property mean? - How does this "hierarchical scope" get reflected in the abstract syntax ? - Which is the owner of this configuration property ? a) The transformation ? b) UML::Attribute ? - Which is the qualified name of such a property, for instance, to access its value? a) MyTransformation::MAX_SIZE ? b) UML::Attribute::MAX_SIZE ? c) MyTransformation::UML::Attribute::MAX_SIZE ? [Suggestion: Reconsider the issue suggestion] Regards, Adolfo. -- On 30/01/2014 11:08, Ed Willink wrote: Hi The proposed resolution currently in ballot 2 /In 8.2.2.23 InstantiationExp add// //referredConstructor : Constructor [0..1]/ introduces a reference from ImperativeOCL to QVTOperational. There is a simple fix: 1) minimal change: Move Constructor from QVTOperational to ImperativeOCL. 2) coherent change: Move Constructor, ConstructorBody, ObjectExp from QVTOperational to ImperativeOCL. Constructing objects is a kind of useful imperative thing to do, so allowing ImperativeOCL to do this seems sensible. ---- The resolution as ballotted is bad so it is withdrawn from ballot 2. A revised resolution will appear in the ballot 3 preview possibly today, probably tomorrow. Regards Ed Willink ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3684/7046 - Release Date: 01/30/14