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
