Issue 19023: Enhance ObjectExp to allow constructors invocation (qvt-rtf) Source: Open Canarias, SL (Mr. Adolfo Sanchez-Barbudo Herrera, nobody) Nature: Enhancement Severity: Minor Summary: Problem: ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified. However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation: constructor Column::ColumnConstructor (n:String,t: String) { name:=n; type:=t; } object result1 : Column (“name”, “String”); object result2 : Column (“age”, “Integer”); Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint. context ObjectExp inv : argument->size() > 0 implies body.oclIsUndefined() Discussion: This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid. Proposed solution: In section 8.2.1.24 add the following subsection: Constraints If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa): context ObjectExp inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and not body.oclIsUndefined() implies argument->isEmpty() In section 8.2.1.24 add the following to the the end notation subsection: Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body: object result1 : Column (“name”, “String”); object result2 : Column (“age”, “Integer”); Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated). In section 8.4.7: Replace: <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator> <expression_block> By: <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator> (<expression_block> | '(' (<declarator_list>)? ')' ) Resolution: Enhance ObjectExp to allow constructors invocation Problem: ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified. However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation: constructor Column::ColumnConstructor (n:String,t: String){ name:=n; type:=t; } object result1 : Column (?name?, ?String?); object result2 : Column (?age?, ?Integer?); Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint. context ObjectExp inv : argument->size() > 0 implies body.oclIsUndefined() Discussion: This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid. Proposed solution: In section 8.2.1.24 add the following subsection: Constraints If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa): context ObjectExp inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and not body.oclIsUndefined() implies argument->isEmpty() In section 8.2.1.24 add the following to the the end notation subsection: Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body: object result1 : Column (?name?, ?String?); object result2 : Column (?age?, ?Integer?); Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated). In section 8.4.7: Replace: <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator> <expression_block> By: <object_exp> ::= 'object' ('(' <iter_declarator> ')')? <object_declarator> (<expression_block> | '(' (<declarator_list>)? ')' ) Discussion This was extensively discussed on the Eclipse qvto-dev mailing list. The conclusion was that the inheritance of ObjectExp from InstantiationExp is pragmatic and causes more problems that it solves. It should be eliminated. Allowing objects to be constructed by a constructor expression rather field assignment is a nice syntax enhancement for significant utility classes. It is hoped that a resolution will be prototyped by: [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=479657 ---------------------------------------------------------------------------------------- [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=479657 Revised Text: Actions taken: October 23, 2013: received issue December 22, 2015: Deferred March 29, 2016: closed issue Discussion: InstantiationExp.initailzationOperation may provide the required AS support. CS needs protyping to determine what dosambiguation rules are required. Disposition: Deferred End of Annotations:===== m: webmaster@omg.org Date: 23 Oct 2013 08:16:17 -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 (QVT) Section: 8.2.1.24 FormalNumber: formal-11-01-01 Version: 1.1 Doc_Year: 2011 Doc_Month: January Doc_Day: 01 Page: 102 Title: Enhance ObjectExp to allow constructors invocation. Nature: Enhancement 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: 08:16 AM Description: Problem: ObjectExp seems to be an enhancement to the InstantationExp due to the additional semantics, however it gets limited due to the fact that every time we need to use it we have to define the constructor body (in constrast to the instantiation expression usage). Although, ObjectExp was conceived to inline object instantiations, this limitation is not justified. However, this limitation could be removed by also allowing an ObjectExp-Constructor combination, in the same way we have for InstantiationExp. The problem relies on a flaky concrete syntax which we could enhance to exploit an ObjectExp with an already defined constructor operation: constructor Column::ColumnConstructor (n:String,t: String) { name:=n; type:=t; } object result1 : Column (.name., .String.); object result2 : Column (.age., .Integer.); Providing a constructor body (from ObjectExp) and a list of arguments (from InstantiationExp) should be prohibited in both, the concrete syntax and the abstract syntax. Regarding the abstract syntax this could be expression with a constraint. context ObjectExp inv : argument->size() > 0 implies body.oclIsUndefined() Discussion: This enhancement seems convenient with no apparent drawbacks, since the old ObjectExp usage remains valid. Proposed solution: In section 8.2.1.24 add the following subsection: Constraints If an object expression contains a constructor body, no arguments for a constructor are allowed (and vice versa): context ObjectExp inv: argument->notEmpty() > 0 implies body.oclIsUndefined() and not body.oclIsUndefined() implies argument->isEmpty() In section 8.2.1.24 add the following to the the end notation subsection: Similarly to InstantiationExp, an object expression could be used to invoke a constructor operation, rather than inlining a constructor body: object result1 : Column (.name., .String.); object result2 : Column (.age., .Integer.); Note that this notation allows us to use object expression to instantiate (or update) objects, while having a reusable constructor in order to initialize (or update) the properties of the object subject to be created (or updated). In section 8.4.7: Replace: ::= 'object' ('(' ')')? By: ::= 'object' ('(' ')')? ( | '(' ()? ')' )