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