[CompleteOCL] operation parameters typed as OclType are not recognised

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 467340 | | Status | NEW | | Importance | P3 normal | | Reported | May 14, 2015 11:59 EDT | | Modified | May 18, 2015 05:25 EDT | | Reporter | Adolfo Sanchez-Barbudo Herrera |

Description

I'm trying to create an OCL operation which receives a type as a parameter. For that I'm using the OclType as the type of the parameter.

Apparently, there are some problems when using this type. There is no problem from the point of view of the caller of the operation, but inside the operation the parameter can't be properly accessed: an error appears in the editor

Exemplary file at : \org.eclipse.qvtd.cs2as.compiler.tests\src\org\eclipse\qvtd\cs2as\compiler\tests\models\example1\Source2Target.ocl

Specific branch number, coming next

Additional question: Would it be easy to define a template parameter, so that the type of the operation (the return type) is the type passed via parameter ?

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on May 14, 2015 12:03

branch (QVTd) asanchez/467340 pushed

[eclipse-ocl-bot]

By Ed Willink on May 18, 2015 04:17

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

Additional question: Would it be easy to define a template parameter, so that the type of the operation (the return type) is the type passed via parameter ?

In principle:

def:(T) opName(type : typeof(T)) : T

Then file a Bugzilla because I probably only demonstrated the grammar compatibility without joining all the dots.

I suspect that typeof is only supported in OCLstdlib.

cf.

operation oclAsType(TT)(type : typeof(TT)) : TT[?] => 'org.eclipse.ocl.pivot.library.oclany.OclAnyOclAsTypeOperation'

You might be better off defining a library for some hard stuff since OCL stdlib declarations are more powerful and have a cleaner syntax than Complete OCL.

My latest branch exploits the QVTd library extension technology to add org.eclipse.ocl.examples.codegen/model/CGLibrary.oclstdlib and associated auto-generation. Operation implementations are in Java but could be in OCL.

[eclipse-ocl-bot]

By Ed Willink on May 18, 2015 04:54

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

For that I'm using the OclType as the type of the parameter. ... there are some problems when using this type.

Prior to the introduction of the "typeof(...)" declaration operator, OclType arguments were special to cope with the irregular nature of oclIsKindOf() arguments.

See if (parameter.isIsTypeof() || (parameter.getTypeId() == standardLibrary.getOclTypeType().getTypeId())) { in EssentialOCLCSLeft2RightVisitor.resolveOperationArgumentTypes

I suspect that the code is a relic, but I'm a bit reluctant to change it right now. It should all get replaced/regularized by the auto-generated EssentialOCLCS2AS.ocl anyway. Deleting it only causes two tests to fail, one a smelly test of my own, and another where UMLDI has a similar problem. If in oclIsKindOf(X), X is viable as both a Type and an (implicit opposite) Property, there is an ambiguity that we obviously want to resolve to the Type. Deleting the relic code and the ambiguity becomes a problem and fails the two tests.

Clearly need a cleaner way of prioritizing Types over implicit Properties.

For now you can use ocl:Type.

[eclipse-ocl-bot]

By Ed Willink on May 18, 2015 05:25

(In reply to Ed Willink from comment #3)

Clearly need a cleaner way of prioritizing Types over implicit Properties.

Small repro test case pushed to ewillink/467340. (asanchez/467340 can be deleted)