Mars RC2 Regression on objectsOfType

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 471170 | | Status | NEW | | Importance | P3 critical | | Reported | Jun 26, 2015 17:35 EDT | | Modified | Jul 30, 2015 14:46 EDT | | Reporter | Ed Willink |

Description

commit ae9ce3d54a7fd729706f4d6817198edb7bbafd5c\ Author: sboyko serg.boyko2011@gmail.com 2015-05-25 11:16:39

[467600] - Provide distinct Model::objectsOfType/objectsOfKind

Good: introduces objectsOfKind (as I suggested as a future proofing)

Bad: changes objectsOfType (breaking existing transformations and deviating from the QVTo specification).

The semantics of objectsOfType should not be changed until a future QVTo justifies/mandates it.

IMHO, for existing users this mandates an "a" release.

Workaround: recode objectsOfType as objectsOfKind.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Jul 30, 2015 13:08

(In reply to Ed Willink from comment #0)

commit ae9ce3d54a7fd729706f4d6817198edb7bbafd5c Author: sboyko serg.boyko2011@gmail.com 2015-05-25 11:16:39

[467600] - Provide distinct Model::objectsOfType/objectsOfKind

Good: introduces objectsOfKind (as I suggested as a future proofing)

Bad: changes objectsOfType (breaking existing transformations and deviating from the QVTo specification).

The semantics of objectsOfType should not be changed until a future QVTo justifies/mandates it.

IMHO, for existing users this mandates an "a" release.

Workaround: recode objectsOfType as objectsOfKind.

The old behavior of 'Model::objectsOfType()' function was not corrected. Function returned not only objects of specified type but also objects of subtypes of the type.

Section '8.3.5.2 objectsOfType' of specification defines that objectsOfType() " Returns the list of the objects in the model extent that have the type given."

Given that new function Model::objectsOfKind() was introduced the behavior of Model::objectsOfType() was fixed.

[eclipse-qvt-oml-bot]

By Ed Willink on Jul 30, 2015 13:48

(In reply to Sergey Boyko from comment #1)

Section '8.3.5.2 objectsOfType' of specification defines that objectsOfType() " Returns the list of the objects in the model extent that have the type given."

The 4 ...OfKind/OfType operations on Objects are consistent and documented clearly as "exact" type.\

Given that new function Model::objectsOfKind() was introduced the behavior of Model::objectsOfType() was fixed.

The specification wording is vague; no corresponding use of "exact type". What we now have is certainly better, but it is a regression that bit me. How many other users will be upset?

I still think objectsOfType should revert.

[eclipse-qvt-oml-bot]

By Adolfo Sanchez-Barbudo Herrera on Jul 30, 2015 14:46

Hi

I think that both have good but conflicting points

The fix is clearly not backwards compatible (many transformations will break). On the other hands, which is the point of include an operation which does exactly the same of the previous one ? Very confusing for users, which will notice the bug if objectsOfType is not corrected.

6 weeks ago, my preferred alternatives would have been:\ a) revert both objectsOfKind addition and objectsOfType behaviour.\ b) assume the backwards incompatibility.

Since the fix is already released in Mars, a) is also not acceptable neither. So it's a matter of the project leader to decide if

• assuming the Mars backwards incompatibility
• assuming the non-sensible existent of different but equivalent operations. Providing the semantics we have for oclIsKind/oclIsType, the situation gets aggravated, because we would be clearly maintaining a bug.

I think that at least, the issue (that existing transformations might break) should properly be communicated in the forum. Ideally ideally in the (likely nonexistent) Luna-Mars migration guide.

BTW, I experienced an issue last week, when launching a transformation using objectsOfKind in standalone mode. The editor recognize the operation, but in standalone mode execution you get a compilation error. I'll raise a separate bug if I'm able to reproduce/report the issue.

Regards,\ Adolfo.