[cs2as] Missing imports

[eclipse-qvtd-bot]

| --- | --- | | Bugzilla Link | 485647 | | Status | NEW | | Importance | P3 normal | | Reported | Jan 12, 2016 07:58 EDT | | Modified | Feb 12, 2016 08:56 EDT | | Reporter | Ed Willink |

Description

Adding a consistency assertion between domain usage and typed models as part of Bug 485616 diagnoses that Ecore and Lookup are not declared as TypedModel.usedPackages in classescs2as.qvtp.qvtias. Both should be part of the rightAS usedPackages.

But since the sole usage of Ecore is "ClassesCS.ElementCS.ast : EObject" and everything in Classes extends from Classes.Element, Ecore can be eliminated by redeclaring as "ClassesCS.ElementCS.ast : Element".

Only Lookup is needed since it is used by rightAS computations.

[eclipse-qvtd-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 12, 2016 08:58

Hi Ed,

It sounds like you are revolving on the same/similar issue I got while ago. There is some commented code @ RootDomainUsageAnalysis (line 400), which I was coding to transitively discover used packages, from those referred by the TypedModel. It was relying on navigating through superClasses, so it might not even work for the issue you have reported here, because analysing types/classes of the Properties would also be required.

Fundamental discussion. Providing we had 10 levels of meta-model extensions, a transformation writer, will not probably want to manually add all those usedPackages by hand. Just refer to specific one he is interested in (e.g. the most derived one)

QVTp is not normally target of transformation writers, so probably XXX2QVTp infrastructure might cope with that. Ok, but we can potentiallly have different transformation XXX2QVTp transformation targeting QVTp , forcing all of them to do the discovery of the actual usedPackages.

So, some questions:

• What TypedModel.usedPackages means, and which is the first QVTx level in which appears ?
• Is QVTm2QVTp doing the discovery of all the actual usedPackages?. Is it automatically done by a previous QVTx2QVTy ? Do they have to manually be written by the transformation writer, let's say QVTr ?
• If computing all the actually used packages is a concern of the domain analysis, should not the actually used packages discovery be done by it.
• If it is a transversal concern for different analysis, shouldn't be a QVTp2QVTp processing to compute them ?

[eclipse-qvtd-bot]

By Ed Willink on Jan 12, 2016 09:06

I think this is primarily a CS2AS issue and can be solved by the initial synthesis. Perhaps

    CS2ASJavaCompilerParameters cgParams = new CS2ASJavaCompilerParametersImpl(\
            "example2.classes.lookup.util.ClassesLookupSolver",\
            "example2.classes.lookup.util.ClassesLookupResult",\
            TESTS_GEN_PATH, TESTS_PACKAGE_NAME);

just needs another parameter or perhaps it is already there.

For the QVT* chain, the used packages should be there at the input, unless they are auto-synthesized in which case the synthesizer should add them.

The consistency check is just that for every computed ClassDatum, the DomainUsage's TYpedMode.usedPackages includes the Class's containing Package.

[eclipse-qvtd-bot]

By Ed Willink on Jan 18, 2016 09:42

The second half of Example5 fails with new scheduler because of this too. The domain analysis considers only sderived and tderived, ignoring sbase and tbase.

[eclipse-qvtd-bot]

By Ed Willink on Jan 18, 2016 11:16

What are the semantics of import? For QVTp, it is our language, so it could be whatever we like, but I prefer to go with QVTc/QVTr.

For QVTbase 7.11.1.2 TypedModel - "At runtime, a model that is passed to the\ transformation by this [TypedModel] name is constrained to contain only those model elements whose types are specified in the set of model packages associated with the typed model."

(Bug: should be "whose types or supertypes are specified")

This is exactly what we need for DomainAnalysis; given some type T, it can be part of every domain whose TypedModel enumerates T's Package in the TypedModel::usedPackages.

---

For QVTp we could try to be helpful and infer TypedModels, but I think it is fraught with danger. Clearly only inheritance/composition can contribute, otherwise every cross-domain reference will fold all models together.

If inheritance/composition are used, we get the low level hazard that Ecore is part of all models. If we demand that Ecore is declared, the EObject everywhere hazards will usually vanish. In your examples ast:EObject can be cleary a RightAS domain since Ecore need only be a TypedModel::usedPackages for the RightAS .

[eclipse-qvtd-bot]

By Ed Willink on Feb 10, 2016 05:33

(In reply to Ed Willink from comment #3)

The second half of Example5 fails with new scheduler because of this too. The domain analysis considers only sderived and tderived, ignoring sbase and tbase.

This seems to have been directly or indirectly fixed. Example 5 now works with the new scheduler. A variety of DomainAnalysis fixes have gone in, some almost howlers. Probably the most useful are the domain unification of LHS/RHS of PropertyAssignment and = and <>. Also the correct narrowing of null usage.

This bug remains open until the fudge that special cases EObject as an undeclared supertype is resolved.

[eclipse-qvtd-bot]

By Adolfo Sanchez-Barbudo Herrera on Feb 12, 2016 08:38

(In reply to Ed Willink from comment #5)

(In reply to Ed Willink from comment #3)

The second half of Example5 fails with new scheduler because of this too. The domain analysis considers only sderived and tderived, ignoring sbase and tbase.

This seems to have been directly or indirectly fixed. Example 5 now works with the new scheduler. A variety of DomainAnalysis fixes have gone in, some almost howlers. Probably the most useful are the domain unification of LHS/RHS of PropertyAssignment and = and <>. Also the correct narrowing of null usage.

"The second half of Example 5" problem was indeed related to CS2AS.

Fixing commit: 74da2cf2b5655c5dfd3233958942e01b6306a870

This bug remains open until the fudge that special cases EObject as an undeclared supertype is resolved.

The problem is that a potential AS meta-model might not have a common supertype for every possible AS element. Therefore EObject must be allowed to be set as the type of traceability property, not to seriously limit the approach.

Ecore obviously allows you include EObject as type of references (to refer an arbitrary model element).

From the point of view QVT and DomainAnalysis, you might find similar problems if you find an OCL operation that returns OclElement or OclAny. You can't narrow the domain of the returned object.

I think that it should be supported, even if it makes the scheduler life harder.

Regards,\ Adolfo.

[eclipse-qvtd-bot]

By Ed Willink on Feb 12, 2016 08:56

(In reply to Adolfo Sanchez-Barbudo Herrera from comment #6)

Therefore EObject must be allowed to be set as the type of traceability property, not to seriously limit the approach.

I could argue that it should be OclElement, but referencing OclElement from an Ecore metamodel is unnecessarily painful and pedantic. And not actually that helpful.

However my objection is not about using EObject, but about failing to declare EObject's Package. If Ecore.ecore or its nsURI, is an Import.usedPackage, then the DomainAnalysis can know in which domains EObject is legitimate. In our examples we know that EObject is used only in the rightAS domain, so declare that. Without the declaration, there is an increased possibility that Operation analysis may fail to identify the domain usage with sufficient precision. ast() and env() are heavily overloaded and so complex to analyze; demanding that the analysis correctly disambiguate an ambiguous domain declaration is creating a needless challenge.

This is probably less important than it was now that a number of DomainAnalysis unification fixes have been made.