Comment 1 Nicolas Rouquette 2011-07-24 18:57:54 EDT

Created attachment 200248 [details]
Proposed patch to OCL and QVTO (R3 maintenance)

This bug is quite problematic for us at JPL.
I have developed this proposed patch.
Is this something that can be incorporated into the maintenance builds for Helios?

Comment 2 Nicolas Rouquette 2011-07-24 21:51:18 EDT

Created attachment 200249 [details]
Revised patch

This revised patch works in my environment.
That is, it is possible to do things like:

var t : Tuple(a=Dict(String,String), b=List(Sequence(String))) 
 = Tuple{a=Dict{}, b=List{}};

Can this patch be incorporated in the Helios maintenance builds?

Comment 3 Nicolas Rouquette 2011-07-24 21:51:20 EDT

Created attachment 200250 [details]
mylyn/context/zip

Comment 4 Nicolas Rouquette 2011-07-27 07:25:28 EDT

Well, I found that the proposed patch isn't enough!

With EcoreEvaluationEnvironemnt.coerceValue protected, we can override it in QvtOperationalEvaluationEnv; however the EcoreEvaluationEnvironment.coerceValue method uses a private UMLReflectionImpl.INSTANCE object to determine what kind of OCL collection corresponds to an EClassifier according to the multiplicity range, uniqueness and ordering meta-properties. 

To make matters worse, there are in fact two UMLReflection mechanisms:

1) qvt.oml.stdlib.QVTUMLReflection -- this is the mechanism that QvtEnvironmentBase.getUMLReflection() provides
2) ocl.ecore.internal.UMLReflectionImpl -- this is a hardcoded mechanism used privately in EcoreEvaluationEnvironment.getCollectionKind

Since this is QVTO.... it seems that the first one is what we should be using instead of OCL's legacy UMLReflection mechanism -- (it seems to me that the OCL UMLReflection mechanism should be in org.eclipse.ocl.uml, not org.eclipse.ocl.ecore)
But, there is a problem to access the QVTUMLReflection!

The QvtOperationalEvaluationEnv.coerceValue method does not have access to the QVTUMLReflection object because QvtOperationalEvaluationEnv extends OCL's EcoreEvaluationEnvironment, not QVTO's QvtEnvironmentBase where QVTOUMLReflection is publicly accessible via QvtEnvironmentBase.getUMLReflection()

That is, the QvtOperationalEvaluationEnv / EcoreEvaluationEnvironment is completely unaware of the existence of QvtEnvironmentBase / EcoreEnvironment.
The proposed strategy is to add an entry in the QvtOperationalEvaluationEnv's binding map to retrieve the QvtEnvironmentBase object from which it will be possible to retrieve the QVTUMLReflection object to determine 
what type to coerce a value to. The qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.execute(OperationalTransformation) method seems appropriate as the place to put this new binding.

- Nicolas.

Comment 5 Nicolas Rouquette 2011-07-28 22:35:31 EDT

Created attachment 200577 [details]
3rd patch, the fix seems to work as intended.

The idea to save a reference to the QvtEnvironmentBase object
so that QVTO can do UML-style coersions and constructions is sound.
The problem is is the details where we have to setup this extra reference and not loose it.

The previous patch was saving this reference in the outermost place in the execution of a QVTO transformation; however, it turned out that eventually, the reference would be lost.

It turns out that there are indeed two ways in which the QvtOperationalEvaluationEnv object is created; the second is more subtle.

So far, here are the two places where the extra environment reference is set.

1) qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.execute(OperationalTransformation) 
2) qvt.oml.evaluator.QvtOperationalEvaluationVisitorImpl.visitInstantiationExp(InstantiationExp)

This 3rd patch seems to be OK on a non-trivial QVTO test.

Comment 6 Nicolas Rouquette 2011-07-28 22:35:37 EDT

Created attachment 200578 [details]
mylyn/context/zip

Comment 7 Christopher Gerking 2014-03-23 07:26:18 EDT

Works for me.

Comment 8 Ed Willink 2014-03-23 07:50:19 EDT

(In reply to Christopher Gerking from comment #7)
> Works for me.

What works?

No patch/the first patch/the second patch.

-----

The saving of mutable types nested within immutable types is unsound. In my QVT traceability paper (http://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf) I conclude that OCL needs a Map type which would then allow QVTo to change List/Dict into Sequence/Map when extending immutable types.

Comment 9 Christopher Gerking 2014-03-23 08:15:22 EDT

Without any patch. The code snippet above does not produce an IllegalArgumentException.