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
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