Replace Section 8.1.13 with the following text to
be placed before the current 8.1.12.
8.1.12 Mapping Overloading
Invocation of a mapping selects a disjunction of
one or more candidate mappings at
compile time. At run-time, the first matching
candidate mapping is selected and
invoked. The disjunction may be specified
explicitly using the
disjuncts keyword or implicitly by an
overloaded mapping.
8.1.12.1 Explicit Disjuncts
In the following example, the explicit
disjunction defines convertFeature as a
disjuncting mapping name that may be
invoked on a UML::Feature with a
Boolean argument. convertAttribute,
convertConstructor and
convertOperation are candidate
mapping names.
mapping UML::Feature::convertFeature(asUpper: Boolean) : JAVA::Element
disjuncts convertAttribute, convertOperation, convertConstructor {}
mapping UML::Attribute::convertAttribute(asUpper: Boolean) : JAVA::Field {
name := if asUpper then name.toUpper() else name endif;
}
mapping UML::Operation::convertConstructor(asUpper: Boolean) : JAVA::Constructor
when {self.name = self.namespace.name;} {
name := if asUpper then name.toUpper() else name endif;
}
mapping UML::Operation::convertOperation(asUpper: Boolean) : JAVA::Constructor
when {self.name <> self.namespace.name;} {
name := if asUpper then name.toUpper() else name endif;
}
The explicit disjuncts causes the
mapping invocation to successively assess the
implicit and explicit predicates of
convertAttribute, convertConstructor
and convertOperation to identify the
first match. If no match is found the mapping
invocation returns
null.
The explicit predicates are provided by arbitrary
constraints specified in
when clauses. Implicit predicates are
provided by the type signatures; each source and
argument must conform to the type of the
disjuncting mapping. An abstract mapping
has a false implicit predicate; an
abstract mapping cannot be executed.
The candidate return type must be
covariant, that is the same as, or derived from
that of, the
disjuncting return type to ensure that no
result incompatibility arises.
Since the argument types contribute to implicit
predicates, the candidate argument types
may be supertypes or subtypes of the
disjuncting mapping. The number of candidate
and disjuncting argument types must be
the same.
An explicit candidate mapping is
identified by its mapping identifier which
identifier may contribute to more than one
disjunction.
8.1.12.2 Implicit Disjuncts
An implicit disjunction groups overloaded
mappings. One mapping overloads another when the
overloading source type extends the overloaded
source type and when the overloading and
overloaded mappings have same name and argument
count.
When UML::Attrbute and UML::Operation
extend UML::Feature, the previous
example may be simplified to use an implicit
disjunction.
mapping UML::Feature::convertFeature(asUpper: Boolean) : JAVA::Element {}
mapping UML::Attribute::convertFeature(asUpper: Boolean) : JAVA::Field {
name := if asUpper then name.toUpper() else name endif;
}
mapping UML::Operation::convertFeature(asUpper: Boolean) : JAVA::Constructor
when {self.name = self.namespace.name;} {
name := if asUpper then name.toUpper() else name endif;
}
mapping UML::Operation::convertFeature(asUpper: Boolean) : JAVA::Constructor
when {self.name <> self.namespace.name;} {
name := if asUpper then name.toUpper() else name endif;
}
he explicit disjuncts provides distinct names and
so facilitates explicit calls direct to the
candidate mappings. The implicit
disjuncts requires no disjuncting
declaration and so faciltates extension by
addition of further contributions.
8.1.12.3 Disjunct candidates
All mappings with the required name, argument and
matching or derived source type are
candidate mappings for the invocation of
a disjuncting mapping. This includes
mappings inherited from extended transformations.
The
candidate mappings referenced in a disjuncting
mapping may introduce new names and consequently a
further disjunction of
candidate mappings; the explicit disjunct
is transitive.
For instance invocation of convertFeature
for a Property in the explicit disjuncts
example should consider a
Property::convertOperation(Boolean)
inherited from an extended transformation since
the explicit disjunct adds
convertOperation to the transitive
candidates. Conversely, the implicit disjunct
example considers only candidates whose signature
is
convertFeature(Boolean).
For non-strict evaluation, a deterministic
evaluation order for evaluation of the predicates
of the candidates as guards is established by
sorting using the following proritized criteria. A
distinction by an earlier criteria overrules all
later criteria.
-
directly invoked explicitly disjuncted candidate
mappings are evaluated in declaration order
-
mappings in the current transformation are
evaluated before those in an extended
transformation, then mappings in an extended
transformation before those in an extended
extended transformation, and so forth
-
mappings for a more derived type are executed
before those for a less derived type
-
mappings are prioritized by alphabetical mapping
name order
-
mappings are prioritized by alphabetical context
type name order
-
mappings are prioritized by alphabetical context
type containing package name order, then by
containing package containing package name
order, and so forth
The ordering above ensures that an extending
transformation can occlude a mapping in an
extended transformation and that a mapping for a
derived type occludes that for a base type. An
implementation may use static analysis of the
predicates to eliminate occluded candidates
completely and to provide reduced candidate lists
according to the source type of the mapping
invocation.
For strict evaluation, the same ordering applies
but the first candidate for which the source type
conforms is selected without evaluating the
predicate as a guard. The predicate is instead
evaluated as a pre-condition giving a
null return when not satisfied.
In the QVTo model and Fig 8.3. Add
MappingOperation ::isAbstract : Boolean[1]
default false.
In 8.2.15 MappingOperation Attributes Add
isAbstract : Boolean[1]
Indicates whether the mapping is abstract,
requiring an overload for all derived context
types. Default is false.
Hi
+1 for choosing the most derived in case of a family of overloaded mappings.
I also like the approach of defining an overload as an implicit disjuncts. In particular, this could simplify the traceability recording rules.
When calling a.doIt() dispatches to B::doIt(), I expect a traceability record for a.resolveIn(A::doIt), even if A::doIt didn't really execute.
For disjuncts, Eclipse QVTo already records traceability links also for the disjuncting mapping. Therefore the above requirement would be fulfilled.
It is more interesting when we have b:B and call b.doIt(). Does it still consult A::doIt() and produce the traceability link for b.resolveIn(A::doIt) ?
Regards
Christopher
-----Ursprüngliche Nachricht-----
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Sonntag, 4. Oktober 2015 13:30
An: QVTOML developer mailing list <qvto-dev@xxxxxxxxxxx>
Betreff: [qvto-dev] What are the mapping refinement rules
Hi
When preparing my "QVT Traceability : What does it really mean?"
presentation to AMT 2015, I was forced to think hard about mapping signatures and their relationships.
https://www.eclipse.org/mmt/qvt/docs/ICMT2014/QVTtraceability.pdf
http://www.slideshare.net/EdWillink/qvt-traceability-what-does-it-really-mean
Declaratively, independent mappings are all invoked independently, dependent mappings such as refinements are arbitrated by their predicates to select the best of a group of related mappings.
Imperatively, it is much simpler, mappings are explicitly invoked, so exactly one compatible mapping is invoked per source object.
The simplest case is the invoked name corresponds to a declared mapping.
More interesting, the invoked name corresponds to a disjuncted mapping allowing the best match of the explicit disjuncts to be invoked, else null.
I am unclear about what happens when the invoked name corresponds to a family of 'overloaded' mappings analoguous to Java operation overloads.
e.g.
mapping A::doIt() : AA {...}
mapping B::doIt() : BB {...}
mapping C::doIt() : CC {...}
where C and B extend A
I presume that in QVTo we choose the most derived analoguously to Java.
I'm inclined to clarify this situation by defining such overloads as implicit disjuncts, so that all colliding names contribute to a disjunct
The example is then equivalent to
mapping A::doIt() : AA
disjuncts B::doIt, C::doIt {...}
mapping B::doIt() : BB {...}
mapping C::doIt() : CC {...}
This could make disjuncts extensible since an extending transformation could supply additional name collisions for the explicitly/implicitly disjuncted mapping.
In order to give deterministic dispatch, the order of disjuncts is:
explicit disjuncts first, then implicit disjuncts successively ordered by the following criteria
- most derived source type,
- most derived first argument type,
- most derived second argument type,
- etc
- alphabetically by containing class name,
- alphabetically by containing class' containing package name,
- etc
The signatures of refinements are unclear. Since a mapping is explicitly invoked, we clearly require that disjuncting mappings have the same number, position and direction of arguments and a covariant
(same/derived) return type. (An explicit disjunct may omit trailing in
arguments.)
Since we are invoking mappings with predicates rather than invoking operations, we may allow disjuncting mappings to also have covariant or even contravariant arguments. When a disjuncting mapping has a distinct in/inout argument type, it is equivalent to an oclIsKindOf() when predicate for that argument type with a subsequent oclAsType() in the body.
Regards
Ed Willink
_______________________________________________
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
_______________________________________________
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: 2015.0.6140 / Virus Database: 4435/10768 - Release Date: 10/06/15