On 07/10/2015 13:16, Ed Willink wrote:
Hi
We could certainly specify that declaratively allInstances() is
computed after loading but before executing.
Unfortunately, this doesn't support the transformation scenario I
exposed, which requires obtaining the instances on outputs. Apart
from not benefiting from the initial caching, I'm still struggling
to see what's wrong with allInstances on outputs. Apparently, I
kinda convinced you about its utility in QVTo, I thought my last
example would do the same with QVTd.... getting closer :P.
If all of this is not convincing to any of us, perhaps it should be
deferred as Sergey suggested. I don't expect you will get better
feedback (well, it would be late anyway) from the RTF during voting
period. Perhaps, you could try to move the specific question to the
RTF mailing-list, to see if there is more luck.
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:
Found a typo:
"The controlled mechanisms ... conflicts" -> "The controlled
mechanisms .... conflict"
Also revise punctuation in that paragraph.
Regards,
Adolfo.
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
_______________________________________________
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
|