eclipse-qvto / org.eclipse.qvto

Eclipse Public License 2.0
0 stars 1 forks source link

Invoking operations from outside their owning modules in debug mode #1042

Open eclipse-qvt-oml-bot opened 3 days ago

eclipse-qvt-oml-bot commented 3 days ago

| --- | --- | | Bugzilla Link | 540577 | | Status | NEW | | Importance | P3 normal | | Reported | Oct 29, 2018 11:00 EDT | | Modified | Oct 29, 2018 12:48 EDT | | Reporter | Christopher Gerking |

Description

When importing a module with access semantics, contextless operations owned by that module are available from the outside as contextual operations of a module instance. Consider the following example:

import NestedTransformation;

transformation RootTransformation() access NestedTransformation;

main() {\ \ new NestedTransformation().myOperation();\ \ }

This snippet compiles, but executes only in run mode. In debug mode, the execution silently crashes with an IllegalArgumentException reporting a "Module-less evaluation environment".

Should these operations be invokable at all? As far as I know, contextual operations are not invokable from the outside, and it is unclear to me why the presence of a context should change the situation.

Why does it fail only in debug mode? This is not the first incident suggesting that the QVTo executor and debugger have been integrated inconsistently, probably with some code duplication that gives rise to a different behavior between modes.

eclipse-qvt-oml-bot commented 3 days ago

By Ed Willink on Oct 29, 2018 12:46

(My way of looking at things ...

QVT unhelpfully defines a Transformation as both a Package and a Class. In Eclipse QVTd for QVTr and QVTc, a Transformation has been simplified to be just a Class. If you want Package(s) they can be wrapped around just like any other Class.

Once a Transformation is just-a-Class, it can sensibly have a self/this instance from which the Operations/Properties of the instance can be exploited by standard navigation. 'contextual' is therefore just a confusing terminology for elaborating the Transformation-Class features. (Global properties/parameters are perhaps static.)

Library is yet another misguided Package+Class that I have not had to consider for QVTr/QVTc. Clearly a Library cannot be a Package so suppose it is just-a-Class. A preliminary consideration of the "the instantiation of the class is always implicit" nonsense...

With non-access semantics, a Library appears to be a form of class inheritance. But how is it accessed? what is the instance name of the Library? is it MyLibrary::this.myHelper()?

"When a library is imported with access semantics, an implicit instance is created and used to access the properties and operations of the library." What is the name of this implicit instance? Presumably "this" got magically extended to be a muit-type! Yuk!

I suggest that the example:

library UmlUtilities(UML1_4)\
extends BasicUmlUtilities(UML1_4)\
access MathLibrary ;

could be more helpfully coded as:

library myUML : UmlUtilities(UML1_4)\
extends BasicUmlUtilities(UML1_4)\
access myMaths : MathLibrary ;

allowing myUML.xx to access the UmlUtilities that extends BasicUmlUtilities and myMaths.yy to access MathLibrary.

eclipse-qvt-oml-bot commented 3 days ago

By Ed Willink on Oct 29, 2018 12:48

Obviously Debug and non-Debug should be the same.

From my consideration in comment#1, access semantics does not appear to be a visibility mechanism, rather a different way of creating an implicit instance.

If you consider my suggestion in comment#1 sensible, see if there is a way to evolve from current Eclipse QVTo pragmatics to comment#1.