On 07/10/2015 14:48, Ed Willink wrote:
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.
Fair enough. I'm not in the QVT RTF (I can't vote againts this
resolution), so the only thing I can do is identify
inconsistencies/mistakes. My last comments:
- "allInstances() is therefore evaluated before input
models are changed."
input models are not changed. Perhaps, you meant transformed.
I'm not familiar how QVTd deals with in-place transformations, but
the same problem (which appear when initially caching
type-2-instances) we discussed for QVTo also should apply in
QVTr/QVTc.
Conclusion:
- I see no fundamental reason to prohibit or constraint
allInstances() usage in QVT (regardless we are talking on QVTo/r/c).
- IMO, there is a clear bias from an implemention (which has not
been clarified) perspective, which doesn't justify the specification
change.
- I can consider any change towards this unnecessary direction, as
prejudicial to the specification. Time will say if that was a good
decision or a bad one.
- I'd be in favor of just adding
suggestions/recommendations/well-practices of not using allInstances
in QVTd transformations (justification related to this, as the one
proposed in the resolution, would be required)
Regards,
Adolfo.
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
_______________________________________________
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
|