Hi
You make a case for QVTc/r to have a Model::objectsOfKind, so that a
cascade of 'transformations' can use domains to communicate and
interrogate them.
We have two weeks before the ballot 4 preview. Deferring an
understood topic is very undesirable because it just means we start
all over again in one/two years time.
Regards
Ed
On 07/10/2015 14:27, Adolfo
Sanchez-Barbudo Herrera wrote:
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
_______________________________________________
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
|
