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