doc/org.eclipse.m2m.qvt.oml.doc/references/breakingChangesInQVTOImplementation.html - mmt/org.eclipse.qvto - Git at Google

 <head>
 	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
 	<link rel="Stylesheet" type="text/css" href="doc.css" />
 	<title>Breaking Changes In QVTO Implementation</title>
 </head>
 <h1>Breaking Changes In QVTO Implementation</h1>
 <p>
 Due to synchronization with the OMG standard specification
 (<a href="http://www.omg.org/docs/ptc/07-07-07.pdf">(MOF) 2.0 Query/View/Transformation</a>) in QVTO 2.0
 a range of breaking changes in the language implementation has been introduced. This section is to
 describe these changes.
 </p>
 <p>
 <h4>Breaking changes list</h4>
 <ul>
   <li><a href="#bug252358">Expressions in mapping population section</a></li>
   <li><a href="#bug253051">Expressions in ObjectExp body</a></li>
   <li><a href="#bug254482">ResolveExp/ResolveInExp implicit source resolution disablement</a></li>
   <li><a href="#bug251064">Keyword reservation</a></li>
 </ul>
 </p>
 <p>
 <h2><a name="bug252358">Expressions in mapping population section</a></h2>
 Usage of expressions within the population section of mappings was highly limited in QVTO 1.x.
 This was significantly improved in QVTO 2.0.
 According to the specification (sections 8.4.7.1, 8.2.1.19, 8.2.1.18 and 8.1.5), it is possible
 to have arbitrary expressions (assignments, variable declarations, if-expressions, etc.) in
 a mapping population section. Furthermore, within an implicit mapping population section
 (i.e. when the <i>population</i> keyword is omitted) properties of the result
 object can be accessed directly.
 <pre class="Code">
 modeltype Ecore uses "http://www.eclipse.org/emf/2002/Ecore";

 transformation test(in dummy : Ecore, out model : Ecore);

 mapping EPackage::toEClass() : EClass {
 	var x := 'ifExp'; -- local variable 'x'
 	if x = 'ifExp' then {
 		name := x; -- assignment to 'name' property of the result object of type EClass
 		           -- same as: result.name := x;
 		name := name + name; -- 'name' property can be directly accessed in any parts of the expression
 		                     -- same as: result.name := result.name + result.name;
 	} else {
 		name := 'wrong'; -- same as: result.name := 'wrong';
 	} endif;
 }
 </pre>
 In case of a mapping with an inout context and without result, this is applicable
 to the properties of the context which is illustrated in the examples in the specification.
 Thus the mapping below is valid:
 <pre class="Code">
 mapping inout EPackage::selfModification() {
 	name := 'initialValue'; -- same as: self.name := 'initialValue';
 }
 </pre>
 As regards the previous implementation, the implicit population section in mappings could only
 consist of assignments to properties of the result object (or the context in case of a mapping with
 an inout context and without result). Moreover the left part of such assignments must have been
 a property name (direct assignment without source). The direct access to properties in the right part
 was unavailable. Thus the mapping below caused a compilation error:
 <pre class="Code">
 mapping EPackage::toEClass() : EClass {
 	name := name; -- in QVTO 1.x this line produced a compilation error
 	              -- since properties in the right part could not be accessed directly
 }
 </pre>
 An important difference between the previous and the new versions is not only the ability to
 use expressions within the mapping population section but also the <b>name clashing resolution</b>.
 As already mentioned, the previous implementation considered the left part of the assignment as a
 property name while the right part was considered to be an ordinary OCL expression where properties
 could not be accessed directly. Therefore, the code below was correct and sensible.
 <pre class="Code">
 mapping EPackage::toEClass(name : String) : EClass {
 	name := name; -- in QVTO 1.x this line was the same as: result.name := name;
 	              -- where 'name' in the right part resolved to the parameter
 }
 </pre>
 The current implementation treats properties in the left part of the assignment the same way as in
 the right part. Moreover, name clashes are resolved to local variables/parameters. This question
 is discussed in the bug comments. Thus in QVTO 2.0 the code above does not compile since it attempts
 to update a read-only parameter:
 <pre class="Code">
 mapping EPackage::toEClass(name : String) : EClass {
 	name := name; -- in QVTO 2.0 this line is the same as: name := name;
 	              -- where 'name' in the expression resolves to the parameter
 	              -- which is read-only
 }
 </pre>
 In the same manner, the example below updates the local variable and hence does not modify the
 corresponding property:
 <pre class="Code">
 mapping EPackage::toEClass() : EClass {
 	var name := 'a'; -- a local variable hiding the corresponding property
 	name := name + 'b'; -- local variable 'name' is updated here
 }
 </pre>

 Note that the behaviour changes only in cases of name clashing and the majority of mappings written in
 QVTO 1.x are to be executed in QVTO 2.0 the same way as before.<br>

 See bug 252358 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=252358">https://bugs.eclipse.org/bugs/show_bug.cgi?id=252358</a>).
 </p>
 <p>
 <h2><a name="bug253051">Expressions in ObjectExp body</a></h2>
 In QVTO 1.x ObjectExp body could only contain assignments to the target object properties.
 In accordance with the specification (sections 8.4.7.1, 8.2.1.18 and 8.1.5), QVTO 2.0 allows
 to have arbitrary expressions (assignments, variable declarations, if-expressions, etc.) in
 an ObjectExp body. Furthermore, within the ObjectExp body properties of the referred
 object can be accessed directly.
 <pre class="Code">
 object a : EClass {
 	var x := 'ifExp'; -- local variable 'x'
 	if x = 'ifExp' then {
 		name := x; -- assignment to 'name' property of the referred object 'a' of type EClass
 		           -- same as: a.name := x;
 		name := name + name; -- 'name' property can be directly accessed in any parts of the expression
 		                     -- same as: a.name := a.name + a.name;
 	} else {
 		name := 'wrong'; -- same as: a.name := 'wrong';
 	} endif;
 }
 </pre>
 As regards the previous implementation, ObjectExp body could only consist of assignments to properties
 of the referred object. Moreover, the left part of such assignments must have been a property name
 (direct assignment without source). The direct access to properties in the right part was unavailable.
 Thus the ObjectExp below caused a compilation error:
 <pre class="Code">
 object a : EClass {
 	name := name; -- in QVTO 1.x this line produced a compilation error
 	              -- since properties in the right part could not be accessed directly
 }
 </pre>
 An important difference between the previous and the new versions is not only the ability to
 use expressions within ObjectExp body but also the <b>name clashing resolution</b>.
 As already mentioned, the previous implementation considered the left part of the assignment as a
 property name while the right part was considered to be an ordinary OCL expression where properties
 could not be accessed directly. Therefore, the code below was correct and sensible.
 <pre class="Code">
 var name := 'a';
 object a : EClass {
 	name := name + 'b'; -- in QVTO 1.x this line was the same as: a.name := name;
 	                    -- where 'name' in the right part resolved to the parameter
 }
 </pre>
 The current implementation treats properties in the left part of the assignment the same way as in
 the right part. Moreover, name clashes are resolved to local variables/parameters. Thus name clashes
 in ObjectExp body and in mapping population section are treated the way.  Thus in QVTO 2.0 the code
 above compiles but produces a completely different result since it updates a local variable:
 <pre class="Code">
 var name := 'a';
 object a : EClass {
 	name := name + 'b'; -- in QVTO 2.0 this line is the same as: name := name;
 	                    -- where 'name' in the expression resolves to the local variable
 	                    -- a.name remains unchanged
 }
 </pre>

 Note that the behaviour changes only in cases of name clashing and the majority of object expressions
 written in QVTO 1.x are to be executed in QVTO 2.0 the same way as before.<br>

 See bug 253051 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=253051">https://bugs.eclipse.org/bugs/show_bug.cgi?id=253051</a>).
 </p>
 <p>
 <h2><a name="bug254482">ResolveExp/ResolveInExp implicit source resolution disablement</a></h2>
 QVTO 1.x performed implicit source lookup for ResolveExp/ResolveInExp expressions. If such lookup was
 successful ResolveExp (consequently, ResolveInExp) was considered to be used with implicit source.
 In this way, the following code was allowed:
 <pre class="Code">
 main() {
 		var a := object EPackage{name := 'a'};
 		var b := object EPackage{name := 'b'};
 		var c := object EPackage{name := 'c'};
 		a.map toEClass(); -- creates a trace record for 'a'
 		b.map toEClass(); -- creates a trace record for 'b'
 		c.map toEClass(); -- creates a trace record for 'c'
 		var x := Bag {a, b} -> collect(resolve()); -- in QVTO 1.x the source of resolve() is the implicit iterator
 		                                           -- of the collect expression
 		                                           -- 'x' becomes a collection of 2 elements
 		var y := Bag {a, b} -> collect(resolveIn(EPackage::toEClass)); -- in QVTO 1.x the source of resolveIn() is the implicit iterator
 		                                                               -- of the collect expression
 		                                                               -- note: this is not a resolveIn() call without source
 		                                                               -- as in the next line.
 		                                                               -- 'y' becomes a collection of 2 elements
 		var z := resolveIn(EPackage::toEClass); -- no implicit source found
 		                                        -- 'z' becomes a collection of 3 elements
 		--var z1 := resolve(); -- implicit source for resolve() not found => compilation error
 }

 mapping EPackage::toEClass() : EClass {
 }
 </pre>

 However, no proof of this concept was found in the specification. Thus, QVTO 2.0 disallowed implicit
 source resolution for ResolveExp/ResolveInExp. Consequently, usage of ResolveExp (not ResolveInExp)
 without source is prohibited and usage of ResolveInExp without source is always considered a search
 though all objects created or updated by the referred mapping (8.2.1.23):
 <pre class="Code">
 main() {
 		var a := object EPackage{name := 'a'};
 		var b := object EPackage{name := 'b'};
 		var c := object EPackage{name := 'c'};
 		a.map toEClass(); -- creates a trace record for 'a'
 		b.map toEClass(); -- creates a trace record for 'b'
 		c.map toEClass(); -- creates a trace record for 'c'
 		--var x := Bag {a, b} -> collect(resolve()); -- in QVTO 2.0 resolve() without source is prohibited
 		var y := Bag {a, b} -> collect(resolveIn(EPackage::toEClass)); -- in QVTO 2.0 this is a resolveIn() call without source
 		                                                               -- as in the next line.
 		                                                               -- 'y' becomes a collection of 6 elements
 		var z := resolveIn(EPackage::toEClass); -- a resolveIn() call without source
 		                                        -- 'z' becomes a collection of 3 elements
 		--var z1 := resolve(); -- in QVTO 2.0 resolve() without source is prohibited
 }

 mapping EPackage::toEClass() : EClass {
 }
 </pre>

 Note that the behaviour changes only in case when ResolveExp/ResolveInExp is used without source and
 there are implicit variables in the corresponding scope (e.g. within collect, select, etc. with
 implicit iterator). Thus the majority of ResolveExp/ResolveInExp expressions written in QVTO 1.x
 are to be executed in QVTO 2.0 the same way as before.<br>

 See bug 254482 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=254482">https://bugs.eclipse.org/bugs/show_bug.cgi?id=254482</a>).
 </p>
 <p>
 <h2><a name="bug251064">Keyword reservation</a></h2>
 QVTO 2.0 reserves all keywords mentioned in the specification (8.4.7.1 Syntax for module definitions, keywords section).
 In addition, QVTO 2.0 also reserves the keyword <i>List</i> mistakenly forgotten in the section and the keyword <i>invalid</i>
 which is not present in the OCL implementation (where <i>Invalid</i> starting from the capital <i>I</i> is used).<br>
 To refer to a named element in case of clashing with keywords, use an underscore prefix "<i>_</i>" as described in the
 <a href="http://www.omg.org/docs/formal/06-05-01.pdf">OCL specification</a> (9.3)<br>

 See bug 251064 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=251064">https://bugs.eclipse.org/bugs/show_bug.cgi?id=251064</a>).
 </p>
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
	<link rel="Stylesheet" type="text/css" href="doc.css" />
	<title>Breaking Changes In QVTO Implementation</title>
	</head>
	<h1>Breaking Changes In QVTO Implementation</h1>
	<p>
	Due to synchronization with the OMG standard specification
	(<a href="http://www.omg.org/docs/ptc/07-07-07.pdf">(MOF) 2.0 Query/View/Transformation</a>) in QVTO 2.0
	a range of breaking changes in the language implementation has been introduced. This section is to
	describe these changes.
	</p>
	<p>
	<h4>Breaking changes list</h4>
	<ul>
	<li><a href="#bug252358">Expressions in mapping population section</a></li>
	<li><a href="#bug253051">Expressions in ObjectExp body</a></li>
	<li><a href="#bug254482">ResolveExp/ResolveInExp implicit source resolution disablement</a></li>
	<li><a href="#bug251064">Keyword reservation</a></li>
	</ul>
	</p>
	<p>
	<h2><a name="bug252358">Expressions in mapping population section</a></h2>
	Usage of expressions within the population section of mappings was highly limited in QVTO 1.x.
	This was significantly improved in QVTO 2.0.
	According to the specification (sections 8.4.7.1, 8.2.1.19, 8.2.1.18 and 8.1.5), it is possible
	to have arbitrary expressions (assignments, variable declarations, if-expressions, etc.) in
	a mapping population section. Furthermore, within an implicit mapping population section
	(i.e. when the <i>population</i> keyword is omitted) properties of the result
	object can be accessed directly.
	<pre class="Code">
	modeltype Ecore uses "http://www.eclipse.org/emf/2002/Ecore";

	transformation test(in dummy : Ecore, out model : Ecore);

	mapping EPackage::toEClass() : EClass {
	var x := 'ifExp'; -- local variable 'x'
	if x = 'ifExp' then {
	name := x; -- assignment to 'name' property of the result object of type EClass
	-- same as: result.name := x;
	name := name + name; -- 'name' property can be directly accessed in any parts of the expression
	-- same as: result.name := result.name + result.name;
	} else {
	name := 'wrong'; -- same as: result.name := 'wrong';
	} endif;
	}
	</pre>
	In case of a mapping with an inout context and without result, this is applicable
	to the properties of the context which is illustrated in the examples in the specification.
	Thus the mapping below is valid:
	<pre class="Code">
	mapping inout EPackage::selfModification() {
	name := 'initialValue'; -- same as: self.name := 'initialValue';
	}
	</pre>
	As regards the previous implementation, the implicit population section in mappings could only
	consist of assignments to properties of the result object (or the context in case of a mapping with
	an inout context and without result). Moreover the left part of such assignments must have been
	a property name (direct assignment without source). The direct access to properties in the right part
	was unavailable. Thus the mapping below caused a compilation error:
	<pre class="Code">
	mapping EPackage::toEClass() : EClass {
	name := name; -- in QVTO 1.x this line produced a compilation error
	-- since properties in the right part could not be accessed directly
	}
	</pre>
	An important difference between the previous and the new versions is not only the ability to
	use expressions within the mapping population section but also the <b>name clashing resolution</b>.
	As already mentioned, the previous implementation considered the left part of the assignment as a
	property name while the right part was considered to be an ordinary OCL expression where properties
	could not be accessed directly. Therefore, the code below was correct and sensible.
	<pre class="Code">
	mapping EPackage::toEClass(name : String) : EClass {
	name := name; -- in QVTO 1.x this line was the same as: result.name := name;
	-- where 'name' in the right part resolved to the parameter
	}
	</pre>
	The current implementation treats properties in the left part of the assignment the same way as in
	the right part. Moreover, name clashes are resolved to local variables/parameters. This question
	is discussed in the bug comments. Thus in QVTO 2.0 the code above does not compile since it attempts
	to update a read-only parameter:
	<pre class="Code">
	mapping EPackage::toEClass(name : String) : EClass {
	name := name; -- in QVTO 2.0 this line is the same as: name := name;
	-- where 'name' in the expression resolves to the parameter
	-- which is read-only
	}
	</pre>
	In the same manner, the example below updates the local variable and hence does not modify the
	corresponding property:
	<pre class="Code">
	mapping EPackage::toEClass() : EClass {
	var name := 'a'; -- a local variable hiding the corresponding property
	name := name + 'b'; -- local variable 'name' is updated here
	}
	</pre>

	Note that the behaviour changes only in cases of name clashing and the majority of mappings written in
	QVTO 1.x are to be executed in QVTO 2.0 the same way as before.<br>

	See bug 252358 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=252358">https://bugs.eclipse.org/bugs/show_bug.cgi?id=252358</a>).
	</p>
	<p>
	<h2><a name="bug253051">Expressions in ObjectExp body</a></h2>
	In QVTO 1.x ObjectExp body could only contain assignments to the target object properties.
	In accordance with the specification (sections 8.4.7.1, 8.2.1.18 and 8.1.5), QVTO 2.0 allows
	to have arbitrary expressions (assignments, variable declarations, if-expressions, etc.) in
	an ObjectExp body. Furthermore, within the ObjectExp body properties of the referred
	object can be accessed directly.
	<pre class="Code">
	object a : EClass {
	var x := 'ifExp'; -- local variable 'x'
	if x = 'ifExp' then {
	name := x; -- assignment to 'name' property of the referred object 'a' of type EClass
	-- same as: a.name := x;
	name := name + name; -- 'name' property can be directly accessed in any parts of the expression
	-- same as: a.name := a.name + a.name;
	} else {
	name := 'wrong'; -- same as: a.name := 'wrong';
	} endif;
	}
	</pre>
	As regards the previous implementation, ObjectExp body could only consist of assignments to properties
	of the referred object. Moreover, the left part of such assignments must have been a property name
	(direct assignment without source). The direct access to properties in the right part was unavailable.
	Thus the ObjectExp below caused a compilation error:
	<pre class="Code">
	object a : EClass {
	name := name; -- in QVTO 1.x this line produced a compilation error
	-- since properties in the right part could not be accessed directly
	}
	</pre>
	An important difference between the previous and the new versions is not only the ability to
	use expressions within ObjectExp body but also the <b>name clashing resolution</b>.
	As already mentioned, the previous implementation considered the left part of the assignment as a
	property name while the right part was considered to be an ordinary OCL expression where properties
	could not be accessed directly. Therefore, the code below was correct and sensible.
	<pre class="Code">
	var name := 'a';
	object a : EClass {
	name := name + 'b'; -- in QVTO 1.x this line was the same as: a.name := name;
	-- where 'name' in the right part resolved to the parameter
	}
	</pre>
	The current implementation treats properties in the left part of the assignment the same way as in
	the right part. Moreover, name clashes are resolved to local variables/parameters. Thus name clashes
	in ObjectExp body and in mapping population section are treated the way. Thus in QVTO 2.0 the code
	above compiles but produces a completely different result since it updates a local variable:
	<pre class="Code">
	var name := 'a';
	object a : EClass {
	name := name + 'b'; -- in QVTO 2.0 this line is the same as: name := name;
	-- where 'name' in the expression resolves to the local variable
	-- a.name remains unchanged
	}
	</pre>

	Note that the behaviour changes only in cases of name clashing and the majority of object expressions
	written in QVTO 1.x are to be executed in QVTO 2.0 the same way as before.<br>

	See bug 253051 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=253051">https://bugs.eclipse.org/bugs/show_bug.cgi?id=253051</a>).
	</p>
	<p>
	<h2><a name="bug254482">ResolveExp/ResolveInExp implicit source resolution disablement</a></h2>
	QVTO 1.x performed implicit source lookup for ResolveExp/ResolveInExp expressions. If such lookup was
	successful ResolveExp (consequently, ResolveInExp) was considered to be used with implicit source.
	In this way, the following code was allowed:
	<pre class="Code">
	main() {
	var a := object EPackage{name := 'a'};
	var b := object EPackage{name := 'b'};
	var c := object EPackage{name := 'c'};
	a.map toEClass(); -- creates a trace record for 'a'
	b.map toEClass(); -- creates a trace record for 'b'
	c.map toEClass(); -- creates a trace record for 'c'
	var x := Bag {a, b} -> collect(resolve()); -- in QVTO 1.x the source of resolve() is the implicit iterator
	-- of the collect expression
	-- 'x' becomes a collection of 2 elements
	var y := Bag {a, b} -> collect(resolveIn(EPackage::toEClass)); -- in QVTO 1.x the source of resolveIn() is the implicit iterator
	-- of the collect expression
	-- note: this is not a resolveIn() call without source
	-- as in the next line.
	-- 'y' becomes a collection of 2 elements
	var z := resolveIn(EPackage::toEClass); -- no implicit source found
	-- 'z' becomes a collection of 3 elements
	--var z1 := resolve(); -- implicit source for resolve() not found => compilation error
	}

	mapping EPackage::toEClass() : EClass {
	}
	</pre>

	However, no proof of this concept was found in the specification. Thus, QVTO 2.0 disallowed implicit
	source resolution for ResolveExp/ResolveInExp. Consequently, usage of ResolveExp (not ResolveInExp)
	without source is prohibited and usage of ResolveInExp without source is always considered a search
	though all objects created or updated by the referred mapping (8.2.1.23):
	<pre class="Code">
	main() {
	var a := object EPackage{name := 'a'};
	var b := object EPackage{name := 'b'};
	var c := object EPackage{name := 'c'};
	a.map toEClass(); -- creates a trace record for 'a'
	b.map toEClass(); -- creates a trace record for 'b'
	c.map toEClass(); -- creates a trace record for 'c'
	--var x := Bag {a, b} -> collect(resolve()); -- in QVTO 2.0 resolve() without source is prohibited
	var y := Bag {a, b} -> collect(resolveIn(EPackage::toEClass)); -- in QVTO 2.0 this is a resolveIn() call without source
	-- as in the next line.
	-- 'y' becomes a collection of 6 elements
	var z := resolveIn(EPackage::toEClass); -- a resolveIn() call without source
	-- 'z' becomes a collection of 3 elements
	--var z1 := resolve(); -- in QVTO 2.0 resolve() without source is prohibited
	}

	mapping EPackage::toEClass() : EClass {
	}
	</pre>

	Note that the behaviour changes only in case when ResolveExp/ResolveInExp is used without source and
	there are implicit variables in the corresponding scope (e.g. within collect, select, etc. with
	implicit iterator). Thus the majority of ResolveExp/ResolveInExp expressions written in QVTO 1.x
	are to be executed in QVTO 2.0 the same way as before.<br>

	See bug 254482 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=254482">https://bugs.eclipse.org/bugs/show_bug.cgi?id=254482</a>).
	</p>
	<p>
	<h2><a name="bug251064">Keyword reservation</a></h2>
	QVTO 2.0 reserves all keywords mentioned in the specification (8.4.7.1 Syntax for module definitions, keywords section).
	In addition, QVTO 2.0 also reserves the keyword <i>List</i> mistakenly forgotten in the section and the keyword <i>invalid</i>
	which is not present in the OCL implementation (where <i>Invalid</i> starting from the capital <i>I</i> is used).<br>
	To refer to a named element in case of clashing with keywords, use an underscore prefix "<i>_</i>" as described in the
	<a href="http://www.omg.org/docs/formal/06-05-01.pdf">OCL specification</a> (9.3)<br>

	See bug 251064 (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=251064">https://bugs.eclipse.org/bugs/show_bug.cgi?id=251064</a>).
	</p>