Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvto-dev] Assigning type expressions

Hi

 

I see. My original use case is actually not to treat imported types as EClassifier, but as some user-defined type (which subclasses EClassifier in order to reside in an EPackage). This allows me to import a standard library package via ‘modeltype’, and enables immediate access to some language-specific standard types such as int, bool, void:

 

 

modeltype myStdLib uses ‘http://…’;

 

var x : MyType = myStdLib::int;

 

 

Of course the above assignment lacks the oclAsType cast and so does not compile. But would it still be wrong to let the compiler exploit its knowledge that myStdLib::int actually conforms to MyType?

 

I know that what I try to do is somewhat unforeseen. Does Pivot provide me a solution as well?

 

 

Kind regards

Christopher

 

 

 

Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Donnerstag, 18. September 2014 23:15
An: qvto-dev@xxxxxxxxxxx
Betreff: Re: [qvto-dev] Assigning type expressions

 

Hi

IMHO it should not compile or run in OMG QVT where the meta-types are poorly defined.

A practical QVT implementation must choose a tooling metamodel and Eclipse QVT makes the very sensible decision to exploit Ecore; however users should not know what tooling technology is used.

It is possible for something perhaps called EQVTo to use EClass etc as the user-visible metamodel in which case oclXXX operations may be interpreted in an Ecore sense giving the behaviour you observe and seek to extend.

But QVT is specified wrt UML/EMOF and so the metatypes for oclXXX are Class not EClass. (EClass can still be the metatype for eClass()).

This is a major pain; see https://bugs.eclipse.org/bugs/show_bug.cgi?id=283052

The Pivot OCL solves this.

    Regards

        Ed Willink



On 18/09/2014 12:32, Christopher Gerking wrote:

Hi again

 

Currently the following statement compiles and runs:

 

var e : EClassifier = ecore::EAnnotation.oclAsType(EClassifier);

 

So why should

var e : EClassifier = ecore::EAnnotation.oclAsType;

not compile? I mean, the compiler could check whether ecore::EAnnotation is an EClassifier or not. So if the underlying technology was not ecore, we would still get the appropriate compile error.

 

Regards

Christopher

 

 

 

 

Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Mittwoch, 17. September 2014 09:53
An: qvto-dev@xxxxxxxxxxx
Betreff: Re: [qvto-dev] Assigning type expressions

 

Hi

The formulation of type expressions in OCL requires implementers to use their intuition.

For the Pivot OCL prototype I modelled them accurately with a new Metaclass(T) type. This wasn't well received by the academic community since it introduced a major enhancement to the type system (e.g. Metaclass(Metaclass(T)) or Set(Metaclass(T))) to solve a comparatively minor problem. I have recently upgraded the Pivot OCL prototype to change Metaclass(T) to typeof(T) as the declaration for operation parameters expecting a type argument such as oclIsKindOf(). typeof(T) just causes a typeof property to be set true rather than introducing a family of type specializations. This works at run-time with minimal impact. At compile time it is necessary to augment OCLExpression.type by an OCLExpression.typeValue to propagate the lower bound of a known type thereby allowing stronger type checking than just any type.

For your specific example:



var e : EClassifier = ecore::EAnnotation;

 

should not compile but



var e : Class = ecore::EAnnotation;


should since you are introducing reflection and while the reflective capabilities of OCL 2.4 are poorly defined, there is no doubt that it is Class not EClass. OCL 2.5 introduces reflection and UML alignment so that it will be well-defined as OCL::Class. Better



var e : typeof(ecore::EAnnotation) = ecore::EAnnotation;


so that the declaration has 'Class' as its 'type' and 'ecore::EAnnotation' as its 'typeValue'. Downstream accesses to 'e' can then use the features of EAnnotation without an oclAsType cast.

OCL 2.5 will also specify what it means to load a model, so loading your model will involve its metamodel being converted to a pivot model representation so that all your model elements conform to the unified metamodel.

Anything you do today using Exxxx is unlikely to be compatible with a future QVT since a future QVT should inherit a clean solution from OCL.

    Regards

        Ed Willink



g a type argument such as








t; e.g. oclIsKindOf().; e.g. oclIsKindOf().






On 17/09/2014 08:10, Christopher Gerking wrote:

Hi

 

What’s your opinion on assignments of type expressions inside QVTo?

 

modeltype ecore uses 'http://www.eclipse.org/emf/2002/Ecore';

 

var e : EClassifier = ecore::EAnnotation;

 

This doesn’t compile, and I wonder if we could make it compile.

The concrete use case that I have in mind is loading of metamodel-specific standard library packages via nsURI, which works. Unfortunately, the packaged custom EClassifiers are not type-compatible with variables of type EClassifier.

 

 

Kind regards

Christopher

 

 

 

 

 





_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev





No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4015/8223 - Release Date: 09/16/14

 




_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev




No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4765 / Virus Database: 4015/8233 - Release Date: 09/18/14

 

Back to the top