Hi
We could certainly specify that declaratively allInstances() is
computed after loading but before executing.
The "specification" of allInstances that I quoted is in 8.3.8. Not
in 11.x where you might expect.
>> - "The properties of individual instances may change as a
result of assignments". Not sure what this >> sentence
contributes to allInstances => Remove it ?
Just trying to highlight that instances may mutate; no cached copies
are referenced.
Editorial comments included in latest draft below:
QVTc/QVTo/QVTr - http://solitaire.omg.org/browse/QVT13-101
Regards
Ed
Add a new sub-clause
6.5 OCL usage in QVT
Essential OCL is used as the expressions language for QVT
Relations, Core and Operational Mappings. Additionally, QVT
Operational Mappings defines an extension of Essential OCL,
named Imperative OCL, to provide the side-effect constructs
required by this imperative language
OCL is a side effect free language that supports evaluation
of constraints on the state of the objects in a model.
(Operation pre- and post-conditions and @pre extend this to
two states.) The controlled mechanisms for object mutation
of the QVT languages conflicts with OCL's expectations of
stability. These conflicts are clarified in this subclause.
.
The declarative QVTc and QVTr languages may cascade
mappings in which OCL evaluations access intermediate
objects. These evaluations occur predictably for either an
old or a new state of an object. An old state is inherently
stable. The new state is stabilized by the declarative
computation of values before usage. An exception however
arises for allInstances() for which the
declarative mapping execution order is difficult for a
programmer to predict with certainty. allInstances()
is therefore evaluated before input models are changed.
The imperative QVTo language performs object mutations as
it advances from one program state to another in a
predictable order. OCL evaluation may be used within each
state. The functionality of allInstances() is
clarified in the Section 8.3.18.
Before "8.3.18 predefined tags" add
Operations on Classifiers
Classifier::allInstances() : Set(T)
The OCL definition is: The operation allInstances()
returns all instances of the classifier and the
classifiers specializing it. May only be used for
classifiers that have a finite number of instances. This
is the case, for example, for user defined classes because
instances need to be created explicitly, and for
enumerations, the standard Boolean type, and other special
types such as OclVoid. This is not the case, for example,
for data types such as collection types or the standard
String, UnlimitedNatural, Integer, and Real types.
This needs clarification for use in an imperative QVTo
context for which OCL's expectation of an unchanging context
is only valid within sub-expressions of an ImperativeExpression.
Successive calls to T::allInstances() may return
different sets of mutable instances during the execution of
the transformation.
Instances are returned from the all model extents for
input, inout and output models. Instances of intermediate
objects are not returned unless they have been added to an
extent. Instances from a metamodel are not returned unless
the metamodel is also an input model. The Model::objectsOfKind()
operation may be used to return selected instances from a
particular model extent.
On 07/10/2015 12:36, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed,
6.5 Clarification is useful, but I don't like "allInstances() is
therefore not available for use by declarative transformations".
In any case, not recommended. Let me expose another simple
example:
1. Imagine I have a transformation a declarative transformation
which from models conforming to XX metamodel we create models
conforming to metamodel YY
2. Then I could create an extending transformation of that one,
with the goal of not only performing the extended transformation,
but it also receives and additional model parameter conformint to
metamodel MM to get some analysis results.
3. I could have additional rules like the following (take the
following as pseudo-code):
rule measureYs
from XX::RootX
to MM::YMeasurement {
numberOfInstances := YY::Y.allInstances()->size()
}
allInstances is useful in this scenario. Why prohibiting it ? Is
there another way to declaratively express this ?
scheduling wise, the rule needs to be executed somewhere after all
rules producing Y have been executed, but I don't see a problem at
all.
*Resuming, allInstances are not normally needed and its usage
might prevent efficient schedules. That said, I believe it should
not be prohibited in QVT, in any case discouraged/not recommended
in declarative languages.*
- I'd set the 6.5 title as "OCL usage in QVT". I'm unsure if it's
better to firstly introduce the relation between OCL and QVT (i.e.
Should the section be 6.1 rather than 6.5). The following
introductory paragraph should be welcomed to the section:
"Essential OCL is reused by the three QVT languages exposed in
this specification. It comprises the expressions language for QVT
Relations, Core and Operational Mappings. Additionally, QVT
Operational Mappings defines an extension of Essential OCL, named
Imperative OCL, to provide the side-effect constructs required by
this imperative language".
Then the "OCL is a side effect free language .... " should nicely
follow
- NB, I looked for QVTc, QVTr, QVTo acronyms. I just found one
QVTc occurrence (probably from a QVT 1.2. issue resolution). I'm
not against to start to using them, but we probably need to
properly introduce them in the specification.
8.3.18
- "The OCL definition is: The operation allInstances()
returns all instances of the classifier and the classifiers
specializing it"
I look for that definition in OCL and I didn't find it. Moreover,
I'm unsure what you want to mean with "and the classifiers
specializing it".
- "and other special types such as OclVoid" . We don't
need/should not be vague here. Which one else... I guess that just
OclInvalid, right ? => "and the special types OclVoid and
OclInvalid"
- "The properties of individual instances may change as a result
of assignments". Not sure what this sentence contributes to
allInstances => Remove it ?
Regards,
Adolfo.
On 06/10/2015 17:45, Ed Willink
wrote:
Hi
A change in OCL is not an option, since there will be no new OCL
specifiction for at least a year.
Another try below.
Regards
Ed
Add a new sub-clause
6.5 Interpretation of the OCL specification
OCL is a side effect free language that supports
evaluation of constraints on the state of the objects in a
model. (Operation pre- and post-conditions and @pre extend
this to two states.) The controlled mechanisms for object
mutation of the QVT languages conflicts with OCL's
expectations of stability. These conflicts are clarified
in this subclause. .
The declarative QVTc and QVTr languages may cascade
mappings in which OCL evaluations access intermediate
objects. These evaluations occur predictably for either an
old or a new state of an object. An old state is
inherently stable. The new state is stabilized by the
declarative computation of values before usage. An
exception however arises for allInstances() for
which the declarative mapping execution order is difficult
for a programmer to predict with certainty. This is not
surprising since the uncertain order is a consequence of
the search for matches traversing all relevant instances
anyway. allInstances() is therefore not
available for use by declarative transformations.
The imperative QVTo language performs object mutations as
it advances from one program state to another in a
predictable order. OCL evaluation may be used within each
state. The functionality of allInstances() is
clarified in the Section 8.3.18.
Before "8.3.18 predefined tags" add
Operations on Classifiers
Classifier::allInstances() : Set(T)
The OCL definition is: The operation allInstances()
returns all instances of the classifier and the
classifiers specializing it. May only be used for
classifiers that have a finite number of instances. This
is the case, for example, for user defined classes
because instances need to be created explicitly, and for
enumerations, the standard Boolean type, and other
special types such as OclVoid. This is not the case, for
example, for data types such as collection types or the
standard String, UnlimitedNatural, Integer, and Real
types.
This needs clarification for use in an imperative QVTo
context for which OCL's expectation of an unchanging
context is only valid within sub-expressions of an ImperativeExpression.
The sets of instances returned by successive calls to T::allInstances()
may grow or shrink during the execution of the
transformation. The properties of individual instances may
change as a result of assignments.
Instances are returned from the all model extents for
input, inout and output models. Instances of intermediate
objects are not returned unless they have been added to an
extent. Instances from a metamodel are not returned unless
the metamodel is also an input model. The Model::objectsOfKind()
operation may be used to return selected instances from a
particular model extent.
On 06/10/2015 13:30, Adolfo
Sanchez-Barbudo Herrera wrote:
On
06/10/2015 11:47, Ed Willink wrote:
allInstances() is underspecified, in
particular the extent from the instances are discovered is
unclear
Hi Ed,
I think that this a problem that should be clarified in OCL,
rather than in QVT. I see allInstances working on a kind of
"Environment" or "Scope" (e.g. ResourceSet in EMF? initial
Resource plus all reachable Resources from it? ). Whatever how
"wide" the scope is something to be considered/clarified for
both OCL and QVT. Ideally, a good clarification in OCL, might
transparently be applied to QVT.
Regards,
Adolfo.
_______________________________________________
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
_______________________________________________
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/10773 - Release
Date: 10/07/15
|