Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » M2M (model-to-model transformation) » [QVTO] Implicit source vs contextless invocation
[QVTO] Implicit source vs contextless invocation [message #72184] Wed, 16 January 2008 16:07 Go to next message
Eclipse UserFriend
Originally posted by: Alexander.Igdalov.borland.com

Hi All,

Operational QVT enables to write some constructions with and without
context. These are mappings and resolveIn expressions. For instance, one
can define two mappings

mapping EClass::a() : EClass {
name := 'a-context';
}

mapping a() : EClass {
name := 'a-contextless';
}

And invoke them this way:

myClass.map a(); -- first mapping
map a(); -- second mapping

The following ambiguity is not resolved in the spec. How should the QVT
engine behave in case of implicit variables in the environment.

Sample:

var d := Sequence { object EClass { name := 'a'},
object EClass { name := 'b'}};
var e := d->collect(map a());

In this case there is an implicit iterator of the 'collect' expression.
That's why 'mapping EClass::a() : EClass' is to be called. On the other
hand, there is a contextless version of mapping a(). Therefore, 'mapping
a() : EClass' is to be called. The question is which mapping is more
preferrable? Or make it a compiler error/warning requiring the user to
change mapping names?

When it comes to resolveIn expressions the situation is even worse,
since 'this' in transformations is always implicit:

var d := Sequence { object EClass { name := 'a'},
object EClass { name := 'b'}};
var f := d->collect(resolveIn(EClass::a, EClass));

What should be used here: sourceless resolveIn or resolveIn on 'collect'
iterator? Apart from collect exps, in case of simple
'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used or
should it be resolveIn on 'this'?

Your thoughts, please?

Best,
Alex.
Re: [QVTO] Implicit source vs contextless invocation [message #72220 is a reply to message #72184] Wed, 16 January 2008 17:57 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 171
Registered: July 2009
Senior Member
Hi Alex,

QVT specification defines mapping operation as follow:
"8.2.1.15 MappingOperation.
A mapping operation is an operation implementing a mapping between one
or more source model elements into one or more target model elements."

And helpers as follow:
"8.2.1.12 Helper
A helper is an operation that performs a computation on one or more
source objects and provides a result."

This means that contextless mapping definition should contain at least
one [in/inout] parameter.
So definition

mapping a() : EClass {
name := 'a-contextless';
}

seems to be incorrect.


There is another possibility for ambiguity. Let's change second mapping
definition to the following:

mapping a(in eCls : EClass) : EClass {
name := 'a-contextless';
}

According to mapping call rule it's not clear what mapping is to be
invoked for the following call:

map a(myClass); -- suited for both mappings definition

I think compilation warning should be produced in such case.
And I believe that for similar situations when it's not clear what
operation/mapping should be invoked warning about invocation ambiguity
is rational solution.


For the resolveIn expression I believe that invocation with context is
preferred that contextless one. In case one explicitly needs contextless
invocation then reference to a transformation instance should be used:

this.resolveIn(EClass::a, EClass)

This call is not ambiguous since it's not allowed to use transformation
instance as mapping source.


Regards,
Sergey.


> Hi All,
>
> Operational QVT enables to write some constructions with and without
> context. These are mappings and resolveIn expressions. For instance, one
> can define two mappings
>
> mapping EClass::a() : EClass {
> name := 'a-context';
> }
>
> mapping a() : EClass {
> name := 'a-contextless';
> }
>
> And invoke them this way:
>
> myClass.map a(); -- first mapping
> map a(); -- second mapping
>
> The following ambiguity is not resolved in the spec. How should the QVT
> engine behave in case of implicit variables in the environment.
>
> Sample:
>
> var d := Sequence { object EClass { name := 'a'},
> object EClass { name := 'b'}};
> var e := d->collect(map a());
>
> In this case there is an implicit iterator of the 'collect' expression.
> That's why 'mapping EClass::a() : EClass' is to be called. On the other
> hand, there is a contextless version of mapping a(). Therefore, 'mapping
> a() : EClass' is to be called. The question is which mapping is more
> preferrable? Or make it a compiler error/warning requiring the user to
> change mapping names?
>
> When it comes to resolveIn expressions the situation is even worse,
> since 'this' in transformations is always implicit:
>
> var d := Sequence { object EClass { name := 'a'},
> object EClass { name := 'b'}};
> var f := d->collect(resolveIn(EClass::a, EClass));
>
> What should be used here: sourceless resolveIn or resolveIn on 'collect'
> iterator? Apart from collect exps, in case of simple
> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used or
> should it be resolveIn on 'this'?
>
> Your thoughts, please?
>
> Best,
> Alex.
Re: [QVTO] Implicit source vs contextless invocation [message #72253 is a reply to message #72220] Wed, 16 January 2008 18:45 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Alexander.Igdalov.borland.com

Hi Sergey,

My comments follow below:

Sergey Boyko wrote:
> Hi Alex,
>
> QVT specification defines mapping operation as follow:
> "8.2.1.15 MappingOperation.
> A mapping operation is an operation implementing a mapping between one
> or more source model elements into one or more target model elements."
>
> And helpers as follow:
> "8.2.1.12 Helper
> A helper is an operation that performs a computation on one or more
> source objects and provides a result."
>
> This means that contextless mapping definition should contain at least
> one [in/inout] parameter.
> So definition
>
> mapping a() : EClass {
> name := 'a-contextless';
> }
>
> seems to be incorrect.
>

Well, this is yet another example that proves that the spec contradicts
itself:) I can point to the example "A.2.4 SPEM UML Profile to SPEM
metamodel" on p. 176 of the spec:

-- rule to create the default process performer singleton
mapping createOrRetrieveDefaultPerformer () : SPEM::ProcessPerformer {
init {
result := resolveoneByRule(createOrRetrieveDefaultPerformer);
if result then return endif;
}
name := "ProcessPerformer";
}

Thus, here we have a ghost of a chance that contextless mappings without
in-parameters still have the right to exist))

>
> There is another possibility for ambiguity. Let's change second mapping
> definition to the following:
>
> mapping a(in eCls : EClass) : EClass {
> name := 'a-contextless';
> }
>
> According to mapping call rule it's not clear what mapping is to be
> invoked for the following call:
>
> map a(myClass); -- suited for both mappings definition
>
> I think compilation warning should be produced in such case.
> And I believe that for similar situations when it's not clear what
> operation/mapping should be invoked warning about invocation ambiguity
> is rational solution.
>
>
> For the resolveIn expression I believe that invocation with context is
> preferred that contextless one. In case one explicitly needs contextless
> invocation then reference to a transformation instance should be used:
>
> this.resolveIn(EClass::a, EClass)
>
> This call is not ambiguous since it's not allowed to use transformation
> instance as mapping source.
>

This idea is not described clearly in the spec, however, we can deduce
it from the additional way of invoking mappings. The following forms are
equivalent:
'this.map class2table(myumlclass);' and 'myumlclass.map class2table()'.
See spec "8.2.1.21 MappingCallExp".

Therefore 'this' cannot be mapped to anything. Thus, it may be used for
purposes like the one above.

>
> Regards,
> Sergey.
>

Best,
Alex.
Re: [QVTO] Implicit source vs contextless invocation [message #72271 is a reply to message #72184] Wed, 16 January 2008 21:55 Go to previous messageGo to next message
Radomil Dvorak is currently offline Radomil DvorakFriend
Messages: 249
Registered: July 2009
Senior Member
Hi Alex,

I have inlined some comments bellow.

Regards,
/Radek

On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov =

<Alexander.Igdalov@borland.com> wrote:

> Hi All,
>
> Operational QVT enables to write some constructions with and without =

> context. These are mappings and resolveIn expressions. For instance, o=
ne =

> can define two mappings
>
> mapping EClass::a() : EClass {
> name :=3D 'a-context';
> }
>
> mapping a() : EClass {
> name :=3D 'a-contextless';
> }
>
> And invoke them this way:
>
> myClass.map a(); -- first mapping
> map a(); -- second mapping
>
> The following ambiguity is not resolved in the spec. How should the QV=
T =

> engine behave in case of implicit variables in the environment.
>
> Sample:
>
> var d :=3D Sequence { object EClass { name :=3D 'a'},
> object EClass { name :=3D 'b'}};
> var e :=3D d->collect(map a());
>
> In this case there is an implicit iterator of the 'collect' expression=
.. =

> That's why 'mapping EClass::a() : EClass' is to be called. On the othe=
r =

> hand, there is a contextless version of mapping a(). Therefore, 'mappi=
ng =

> a() : EClass' is to be called. The question is which mapping is more =

> preferrable? Or make it a compiler error/warning requiring the user to=
=

> change mapping names?

This ambiguity is solved by OCL spec, so collect should take the most =

inner scope first,
in which case it resolves to 'mapping EClass::a() : EClass' as the =

implicit iterator variable
is of type EClass.
As QVT claims to extend OCL, though it's not completely true:), in this =
=

case it
should execute the same.

Provided that the above contextual mapping for EClass is already defined=
, =

a mapping of the signature
bellow should not be allowed and compilation error produced.
mapping a(in EClass);

The reason is that the first contextual definition introduces also the =

non-contextual variant into the
namespace of the defining transformation.

>
> When it comes to resolveIn expressions the situation is even worse, =

> since 'this' in transformations is always implicit:
>
> var d :=3D Sequence { object EClass { name :=3D 'a'},
> object EClass { name :=3D 'b'}};
> var f :=3D d->collect(resolveIn(EClass::a, EClass));
>
> What should be used here: sourceless resolveIn or resolveIn on 'collec=
t' =

> iterator? Apart from collect exps, in case of simple =

> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used or =
=

> should it be resolveIn on 'this'?

I think, 8.1.16 section of the QVT spec could be used to solve this =

problem.
It states that 'this' can be used implicitly with transformation =

properties, operations,
which 'resolveIn' is not.
To be consistent with what I have said above, 'resolveIn' used in collle=
ct =

should resolve to the iterator variable
as the source.
In case the most inner scope would be a transformation, 'resolveIn' is =

without source, as
it should not be used with implicit 'this' and executes according to =

optional source semantics
of ResolveInExp, 8.2.1.23.

>
> Your thoughts, please?
>
> Best,
> Alex.



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [QVTO] Implicit source vs contextless invocation [message #72323 is a reply to message #72271] Thu, 17 January 2008 11:24 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Alexander.Igdalov.borland.com

Hi Radek,

My comments are below.

Radek Dvorak wrote:
> Hi Alex,
>
> I have inlined some comments bellow.
>
> Regards,
> /Radek
>
> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov
> <Alexander.Igdalov@borland.com> wrote:
>
>> Hi All,
>>
>> Operational QVT enables to write some constructions with and without
>> context. These are mappings and resolveIn expressions. For instance,
>> one can define two mappings
>>
>> mapping EClass::a() : EClass {
>> name := 'a-context';
>> }
>>
>> mapping a() : EClass {
>> name := 'a-contextless';
>> }
>>
>> And invoke them this way:
>>
>> myClass.map a(); -- first mapping
>> map a(); -- second mapping
>>
>> The following ambiguity is not resolved in the spec. How should the
>> QVT engine behave in case of implicit variables in the environment.
>>
>> Sample:
>>
>> var d := Sequence { object EClass { name := 'a'},
>> object EClass { name := 'b'}};
>> var e := d->collect(map a());
>>
>> In this case there is an implicit iterator of the 'collect'
>> expression. That's why 'mapping EClass::a() : EClass' is to be called.
>> On the other hand, there is a contextless version of mapping a().
>> Therefore, 'mapping a() : EClass' is to be called. The question is
>> which mapping is more preferrable? Or make it a compiler error/warning
>> requiring the user to change mapping names?
>
> This ambiguity is solved by OCL spec, so collect should take the most
> inner scope first,
> in which case it resolves to 'mapping EClass::a() : EClass' as the
> implicit iterator variable
> is of type EClass.

That is good if the spec is clear about it. But where exactly is this done?

> As QVT claims to extend OCL, though it's not completely true:), in this
> case it
> should execute the same.
>
> Provided that the above contextual mapping for EClass is already
> defined, a mapping of the signature
> bellow should not be allowed and compilation error produced.
> mapping a(in EClass);
>
> The reason is that the first contextual definition introduces also the
> non-contextual variant into the
> namespace of the defining transformation.

Could you prove it, too?

>
>>
>> When it comes to resolveIn expressions the situation is even worse,
>> since 'this' in transformations is always implicit:
>>
>> var d := Sequence { object EClass { name := 'a'},
>> object EClass { name := 'b'}};
>> var f := d->collect(resolveIn(EClass::a, EClass));
>>
>> What should be used here: sourceless resolveIn or resolveIn on
>> 'collect' iterator? Apart from collect exps, in case of simple
>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used or
>> should it be resolveIn on 'this'?
>
> I think, 8.1.16 section of the QVT spec could be used to solve this
> problem.
> It states that 'this' can be used implicitly with transformation
> properties, operations,
> which 'resolveIn' is not.
> To be consistent with what I have said above, 'resolveIn' used in
> colllect should resolve to the iterator variable
> as the source.
> In case the most inner scope would be a transformation, 'resolveIn' is
> without source, as
> it should not be used with implicit 'this' and executes according to
> optional source semantics
> of ResolveInExp, 8.2.1.23.
>
>>
>> Your thoughts, please?
>>
>> Best,
>> Alex.
>
>
>
Re: [QVTO] Implicit source vs contextless invocation [message #72341 is a reply to message #72323] Thu, 17 January 2008 11:46 Go to previous messageGo to next message
Radomil Dvorak is currently offline Radomil DvorakFriend
Messages: 249
Registered: July 2009
Senior Member
On Thu, 17 Jan 2008 12:24:11 +0100, Alexander Igdalov =

<Alexander.Igdalov@borland.com> wrote:

> Hi Radek,
>
> My comments are below.
>
> Radek Dvorak wrote:
>> Hi Alex,
>> I have inlined some comments bellow.
>> Regards,
>> /Radek
>> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov =

>> <Alexander.Igdalov@borland.com> wrote:
>>
>>> Hi All,
>>>
>>> Operational QVT enables to write some constructions with and without=
=

>>> context. These are mappings and resolveIn expressions. For instance,=
=

>>> one can define two mappings
>>>
>>> mapping EClass::a() : EClass {
>>> name :=3D 'a-context';
>>> }
>>>
>>> mapping a() : EClass {
>>> name :=3D 'a-contextless';
>>> }
>>>
>>> And invoke them this way:
>>>
>>> myClass.map a(); -- first mapping
>>> map a(); -- second mapping
>>>
>>> The following ambiguity is not resolved in the spec. How should the =
=

>>> QVT engine behave in case of implicit variables in the environment.
>>>
>>> Sample:
>>>
>>> var d :=3D Sequence { object EClass { name :=3D 'a'},
>>> object EClass { name :=3D 'b'}};
>>> var e :=3D d->collect(map a());
>>>
>>> In this case there is an implicit iterator of the 'collect' =

>>> expression. That's why 'mapping EClass::a() : EClass' is to be calle=
d. =

>>> On the other hand, there is a contextless version of mapping a(). =

>>> Therefore, 'mapping a() : EClass' is to be called. The question is =

>>> which mapping is more preferrable? Or make it a compiler error/warni=
ng =

>>> requiring the user to change mapping names?
>> This ambiguity is solved by OCL spec, so collect should take the mos=
t =

>> inner scope first,
>> in which case it resolves to 'mapping EClass::a() : EClass' as the =

>> implicit iterator variable
>> is of type EClass.
>
> That is good if the spec is clear about it. But where exactly is this =
=

> done?

See OCL spec, 7.8 Resolving Properties

>
>> As QVT claims to extend OCL, though it's not completely true:), in th=
is =

>> case it
>> should execute the same.
>> Provided that the above contextual mapping for EClass is already =

>> defined, a mapping of the signature
>> bellow should not be allowed and compilation error produced.
>> mapping a(in EClass);
>> The reason is that the first contextual definition introduces also t=
he =

>> non-contextual variant into the
>> namespace of the defining transformation.
>
> Could you prove it, too?

Not sure what kind of proof you expect ;-) but the following sections =

worked for me:
QVT spec, 8.2.1.10 ImperativeOperation and 8.2.1.21 MappingCallExp.

>
>>
>>>
>>> When it comes to resolveIn expressions the situation is even worse, =
=

>>> since 'this' in transformations is always implicit:
>>>
>>> var d :=3D Sequence { object EClass { name :=3D 'a'},
>>> object EClass { name :=3D 'b'}};
>>> var f :=3D d->collect(resolveIn(EClass::a, EClass));
>>>
>>> What should be used here: sourceless resolveIn or resolveIn on =

>>> 'collect' iterator? Apart from collect exps, in case of simple =

>>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used o=
r =

>>> should it be resolveIn on 'this'?
>> I think, 8.1.16 section of the QVT spec could be used to solve this =
=

>> problem.
>> It states that 'this' can be used implicitly with transformation =

>> properties, operations,
>> which 'resolveIn' is not.
>> To be consistent with what I have said above, 'resolveIn' used in =

>> colllect should resolve to the iterator variable
>> as the source.
>> In case the most inner scope would be a transformation, 'resolveIn' i=
s =

>> without source, as
>> it should not be used with implicit 'this' and executes according to =
=

>> optional source semantics
>> of ResolveInExp, 8.2.1.23.
>>
>>>
>>> Your thoughts, please?
>>>
>>> Best,
>>> Alex.
>>



-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [QVTO] Implicit source vs contextless invocation [message #72357 is a reply to message #72341] Thu, 17 January 2008 12:11 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Alexander.Igdalov.borland.com

Radek Dvorak wrote:
> On Thu, 17 Jan 2008 12:24:11 +0100, Alexander Igdalov
> <Alexander.Igdalov@borland.com> wrote:
>
>> Hi Radek,
>>
>> My comments are below.
>>
>> Radek Dvorak wrote:
>>> Hi Alex,
>>> I have inlined some comments bellow.
>>> Regards,
>>> /Radek
>>> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov
>>> <Alexander.Igdalov@borland.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Operational QVT enables to write some constructions with and without
>>>> context. These are mappings and resolveIn expressions. For instance,
>>>> one can define two mappings
>>>>
>>>> mapping EClass::a() : EClass {
>>>> name := 'a-context';
>>>> }
>>>>
>>>> mapping a() : EClass {
>>>> name := 'a-contextless';
>>>> }
>>>>
>>>> And invoke them this way:
>>>>
>>>> myClass.map a(); -- first mapping
>>>> map a(); -- second mapping
>>>>
>>>> The following ambiguity is not resolved in the spec. How should the
>>>> QVT engine behave in case of implicit variables in the environment.
>>>>
>>>> Sample:
>>>>
>>>> var d := Sequence { object EClass { name := 'a'},
>>>> object EClass { name := 'b'}};
>>>> var e := d->collect(map a());
>>>>
>>>> In this case there is an implicit iterator of the 'collect'
>>>> expression. That's why 'mapping EClass::a() : EClass' is to be
>>>> called. On the other hand, there is a contextless version of mapping
>>>> a(). Therefore, 'mapping a() : EClass' is to be called. The question
>>>> is which mapping is more preferrable? Or make it a compiler
>>>> error/warning requiring the user to change mapping names?
>>> This ambiguity is solved by OCL spec, so collect should take the
>>> most inner scope first,
>>> in which case it resolves to 'mapping EClass::a() : EClass' as the
>>> implicit iterator variable
>>> is of type EClass.
>>
>> That is good if the spec is clear about it. But where exactly is this
>> done?
>
> See OCL spec, 7.8 Resolving Properties
>

To my mind, this section is about the priority of implicit variables in
case the source is expected. In other words, the section just says that
the most inner scope implicit variables are preferred to implicit
variables of other scopes. However, it doesn't state what to do in case
when there are operations without source.

>>
>>> As QVT claims to extend OCL, though it's not completely true:), in
>>> this case it
>>> should execute the same.
>>> Provided that the above contextual mapping for EClass is already
>>> defined, a mapping of the signature
>>> bellow should not be allowed and compilation error produced.
>>> mapping a(in EClass);
>>> The reason is that the first contextual definition introduces also
>>> the non-contextual variant into the
>>> namespace of the defining transformation.
>>
>> Could you prove it, too?
>
> Not sure what kind of proof you expect ;-) but the following sections
> worked for me:
> QVT spec, 8.2.1.10 ImperativeOperation and 8.2.1.21 MappingCallExp.
>

I expect some phrase from the spec saying that 'mapping EClass::a()'
introduces 'mapping a(in EClass)' as well;-)

>>
>>>
>>>>
>>>> When it comes to resolveIn expressions the situation is even worse,
>>>> since 'this' in transformations is always implicit:
>>>>
>>>> var d := Sequence { object EClass { name := 'a'},
>>>> object EClass { name := 'b'}};
>>>> var f := d->collect(resolveIn(EClass::a, EClass));
>>>>
>>>> What should be used here: sourceless resolveIn or resolveIn on
>>>> 'collect' iterator? Apart from collect exps, in case of simple
>>>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used
>>>> or should it be resolveIn on 'this'?
>>> I think, 8.1.16 section of the QVT spec could be used to solve this
>>> problem.
>>> It states that 'this' can be used implicitly with transformation
>>> properties, operations,
>>> which 'resolveIn' is not.
>>> To be consistent with what I have said above, 'resolveIn' used in
>>> colllect should resolve to the iterator variable
>>> as the source.
>>> In case the most inner scope would be a transformation, 'resolveIn'
>>> is without source, as
>>> it should not be used with implicit 'this' and executes according to
>>> optional source semantics
>>> of ResolveInExp, 8.2.1.23.
>>>
>>>>
>>>> Your thoughts, please?
>>>>
>>>> Best,
>>>> Alex.
>>>
>
>
>
Re: [QVTO] Implicit source vs contextless invocation [message #72538 is a reply to message #72357] Fri, 18 January 2008 12:44 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: research.opencanarias.com

Hi all,

> var d := Sequence { object EClass { name := 'a'},
> object EClass { name := 'b'}};
> var e := d->collect(map a());

Well in this case, the Sequence is defined as a Sequence whose objects
are of type EClass, so when collecting over the variable 'd' the
expression refers to the objects of the collection, therefore the
EClass:a mapping should be implicitly invoked...

This equivalent expression perhaps could help...

var e := d->collect(aVariable : EClass | aVariable.map a());

Besides, as Sergey comments, a non-contextual mapping without parameters
should not be allowed, since it doesn't make sense.

The Sergey's case where you can define a non-contextual mapping with a
parameter, whose type is the context of another contextual mapping
without parameters, is dangerous (and ambiguous) because we have 2
different mappings implemented for the same purposes (Work on the same
element)...It could seem that both mapping could differenced when
invoking them, but since the contextual parameter can be established as
the first argument of the mapping call expression (and not having a
source for the MCE), this differentiation is not possible. So i think
that 2 actions could be taken:

1. Throw an error, as you would have declared the same mapping twice.
2. Consider that the contextual mapping is the correct, and throw a
warning indicating that the non-contextual mapping will never be executed.

The second is the action that I'm taking. I know that the specification
haven't concerned/realized about this kind of problems, but this kind of
work would help to specifications to be refined/clarified/improved.

Best Regards,
Adolfo.

Alexander Igdalov escribió:
> Radek Dvorak wrote:
>> On Thu, 17 Jan 2008 12:24:11 +0100, Alexander Igdalov
>> <Alexander.Igdalov@borland.com> wrote:
>>
>>> Hi Radek,
>>>
>>> My comments are below.
>>>
>>> Radek Dvorak wrote:
>>>> Hi Alex,
>>>> I have inlined some comments bellow.
>>>> Regards,
>>>> /Radek
>>>> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov
>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Operational QVT enables to write some constructions with and
>>>>> without context. These are mappings and resolveIn expressions. For
>>>>> instance, one can define two mappings
>>>>>
>>>>> mapping EClass::a() : EClass {
>>>>> name := 'a-context';
>>>>> }
>>>>>
>>>>> mapping a() : EClass {
>>>>> name := 'a-contextless';
>>>>> }
>>>>>
>>>>> And invoke them this way:
>>>>>
>>>>> myClass.map a(); -- first mapping
>>>>> map a(); -- second mapping
>>>>>
>>>>> The following ambiguity is not resolved in the spec. How should the
>>>>> QVT engine behave in case of implicit variables in the environment.
>>>>>
>>>>> Sample:
>>>>>
>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>> object EClass { name := 'b'}};
>>>>> var e := d->collect(map a());
>>>>>
>>>>> In this case there is an implicit iterator of the 'collect'
>>>>> expression. That's why 'mapping EClass::a() : EClass' is to be
>>>>> called. On the other hand, there is a contextless version of
>>>>> mapping a(). Therefore, 'mapping a() : EClass' is to be called. The
>>>>> question is which mapping is more preferrable? Or make it a
>>>>> compiler error/warning requiring the user to change mapping names?
>>>> This ambiguity is solved by OCL spec, so collect should take the
>>>> most inner scope first,
>>>> in which case it resolves to 'mapping EClass::a() : EClass' as the
>>>> implicit iterator variable
>>>> is of type EClass.
>>>
>>> That is good if the spec is clear about it. But where exactly is this
>>> done?
>>
>> See OCL spec, 7.8 Resolving Properties
>>
>
> To my mind, this section is about the priority of implicit variables in
> case the source is expected. In other words, the section just says that
> the most inner scope implicit variables are preferred to implicit
> variables of other scopes. However, it doesn't state what to do in case
> when there are operations without source.
>
>>>
>>>> As QVT claims to extend OCL, though it's not completely true:), in
>>>> this case it
>>>> should execute the same.
>>>> Provided that the above contextual mapping for EClass is already
>>>> defined, a mapping of the signature
>>>> bellow should not be allowed and compilation error produced.
>>>> mapping a(in EClass);
>>>> The reason is that the first contextual definition introduces also
>>>> the non-contextual variant into the
>>>> namespace of the defining transformation.
>>>
>>> Could you prove it, too?
>>
>> Not sure what kind of proof you expect ;-) but the following sections
>> worked for me:
>> QVT spec, 8.2.1.10 ImperativeOperation and 8.2.1.21 MappingCallExp.
>>
>
> I expect some phrase from the spec saying that 'mapping EClass::a()'
> introduces 'mapping a(in EClass)' as well;-)
>
>>>
>>>>
>>>>>
>>>>> When it comes to resolveIn expressions the situation is even worse,
>>>>> since 'this' in transformations is always implicit:
>>>>>
>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>> object EClass { name := 'b'}};
>>>>> var f := d->collect(resolveIn(EClass::a, EClass));
>>>>>
>>>>> What should be used here: sourceless resolveIn or resolveIn on
>>>>> 'collect' iterator? Apart from collect exps, in case of simple
>>>>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used
>>>>> or should it be resolveIn on 'this'?
>>>> I think, 8.1.16 section of the QVT spec could be used to solve this
>>>> problem.
>>>> It states that 'this' can be used implicitly with transformation
>>>> properties, operations,
>>>> which 'resolveIn' is not.
>>>> To be consistent with what I have said above, 'resolveIn' used in
>>>> colllect should resolve to the iterator variable
>>>> as the source.
>>>> In case the most inner scope would be a transformation, 'resolveIn'
>>>> is without source, as
>>>> it should not be used with implicit 'this' and executes according to
>>>> optional source semantics
>>>> of ResolveInExp, 8.2.1.23.
>>>>
>>>>>
>>>>> Your thoughts, please?
>>>>>
>>>>> Best,
>>>>> Alex.
>>>>
>>
>>
>>
Re: [QVTO] Implicit source vs contextless invocation [message #72574 is a reply to message #72538] Fri, 18 January 2008 13:39 Go to previous messageGo to next message
Radomil Dvorak is currently offline Radomil DvorakFriend
Messages: 249
Registered: July 2009
Senior Member
Hi Adolfo,

If taking the action 2), I just wonder how you handle a call written as
bellow:

var eClass : EClass := ...;

this.map a(eClass); -- provided that mapping EClass::a(); mapping a(in
c:EClass); definitions are allowed

Would this call expression be allowed?
AFAIU, you allow both definitions contextual, non-contextual and the
warning is targeted to the non-contextual def.
as the never executed one.

Regards,
/Radek


On Fri, 18 Jan 2008 13:44:13 +0100, Adolfo Sánchez-Barbudo Herrera
<research@opencanarias.com> wrote:

> Hi all,
>
> > var d := Sequence { object EClass { name := 'a'},
> > object EClass { name := 'b'}};
> > var e := d->collect(map a());
>
> Well in this case, the Sequence is defined as a Sequence whose objects
> are of type EClass, so when collecting over the variable 'd' the
> expression refers to the objects of the collection, therefore the
> EClass:a mapping should be implicitly invoked...
>
> This equivalent expression perhaps could help...
>
> var e := d->collect(aVariable : EClass | aVariable.map a());
>
> Besides, as Sergey comments, a non-contextual mapping without parameters
> should not be allowed, since it doesn't make sense.
>
> The Sergey's case where you can define a non-contextual mapping with a
> parameter, whose type is the context of another contextual mapping
> without parameters, is dangerous (and ambiguous) because we have 2
> different mappings implemented for the same purposes (Work on the same
> element)...It could seem that both mapping could differenced when
> invoking them, but since the contextual parameter can be established as
> the first argument of the mapping call expression (and not having a
> source for the MCE), this differentiation is not possible. So i think
> that 2 actions could be taken:
>
> 1. Throw an error, as you would have declared the same mapping twice.
> 2. Consider that the contextual mapping is the correct, and throw a
> warning indicating that the non-contextual mapping will never be
> executed.
>
> The second is the action that I'm taking. I know that the specification
> haven't concerned/realized about this kind of problems, but this kind of
> work would help to specifications to be refined/clarified/improved.
>
> Best Regards,
> Adolfo.
>
> Alexander Igdalov escribió:
>> Radek Dvorak wrote:
>>> On Thu, 17 Jan 2008 12:24:11 +0100, Alexander Igdalov
>>> <Alexander.Igdalov@borland.com> wrote:
>>>
>>>> Hi Radek,
>>>>
>>>> My comments are below.
>>>>
>>>> Radek Dvorak wrote:
>>>>> Hi Alex,
>>>>> I have inlined some comments bellow.
>>>>> Regards,
>>>>> /Radek
>>>>> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov
>>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Operational QVT enables to write some constructions with and
>>>>>> without context. These are mappings and resolveIn expressions. For
>>>>>> instance, one can define two mappings
>>>>>>
>>>>>> mapping EClass::a() : EClass {
>>>>>> name := 'a-context';
>>>>>> }
>>>>>>
>>>>>> mapping a() : EClass {
>>>>>> name := 'a-contextless';
>>>>>> }
>>>>>>
>>>>>> And invoke them this way:
>>>>>>
>>>>>> myClass.map a(); -- first mapping
>>>>>> map a(); -- second mapping
>>>>>>
>>>>>> The following ambiguity is not resolved in the spec. How should the
>>>>>> QVT engine behave in case of implicit variables in the environment.
>>>>>>
>>>>>> Sample:
>>>>>>
>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>> object EClass { name := 'b'}};
>>>>>> var e := d->collect(map a());
>>>>>>
>>>>>> In this case there is an implicit iterator of the 'collect'
>>>>>> expression. That's why 'mapping EClass::a() : EClass' is to be
>>>>>> called. On the other hand, there is a contextless version of
>>>>>> mapping a(). Therefore, 'mapping a() : EClass' is to be called. The
>>>>>> question is which mapping is more preferrable? Or make it a
>>>>>> compiler error/warning requiring the user to change mapping names?
>>>>> This ambiguity is solved by OCL spec, so collect should take the
>>>>> most inner scope first,
>>>>> in which case it resolves to 'mapping EClass::a() : EClass' as the
>>>>> implicit iterator variable
>>>>> is of type EClass.
>>>>
>>>> That is good if the spec is clear about it. But where exactly is this
>>>> done?
>>>
>>> See OCL spec, 7.8 Resolving Properties
>>>
>> To my mind, this section is about the priority of implicit variables
>> in case the source is expected. In other words, the section just says
>> that the most inner scope implicit variables are preferred to implicit
>> variables of other scopes. However, it doesn't state what to do in case
>> when there are operations without source.
>>
>>>>
>>>>> As QVT claims to extend OCL, though it's not completely true:), in
>>>>> this case it
>>>>> should execute the same.
>>>>> Provided that the above contextual mapping for EClass is already
>>>>> defined, a mapping of the signature
>>>>> bellow should not be allowed and compilation error produced.
>>>>> mapping a(in EClass);
>>>>> The reason is that the first contextual definition introduces also
>>>>> the non-contextual variant into the
>>>>> namespace of the defining transformation.
>>>>
>>>> Could you prove it, too?
>>>
>>> Not sure what kind of proof you expect ;-) but the following sections
>>> worked for me:
>>> QVT spec, 8.2.1.10 ImperativeOperation and 8.2.1.21 MappingCallExp.
>>>
>> I expect some phrase from the spec saying that 'mapping EClass::a()'
>> introduces 'mapping a(in EClass)' as well;-)
>>
>>>>
>>>>>
>>>>>>
>>>>>> When it comes to resolveIn expressions the situation is even worse,
>>>>>> since 'this' in transformations is always implicit:
>>>>>>
>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>> object EClass { name := 'b'}};
>>>>>> var f := d->collect(resolveIn(EClass::a, EClass));
>>>>>>
>>>>>> What should be used here: sourceless resolveIn or resolveIn on
>>>>>> 'collect' iterator? Apart from collect exps, in case of simple
>>>>>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used
>>>>>> or should it be resolveIn on 'this'?
>>>>> I think, 8.1.16 section of the QVT spec could be used to solve this
>>>>> problem.
>>>>> It states that 'this' can be used implicitly with transformation
>>>>> properties, operations,
>>>>> which 'resolveIn' is not.
>>>>> To be consistent with what I have said above, 'resolveIn' used in
>>>>> colllect should resolve to the iterator variable
>>>>> as the source.
>>>>> In case the most inner scope would be a transformation, 'resolveIn'
>>>>> is without source, as
>>>>> it should not be used with implicit 'this' and executes according to
>>>>> optional source semantics
>>>>> of ResolveInExp, 8.2.1.23.
>>>>>
>>>>>>
>>>>>> Your thoughts, please?
>>>>>>
>>>>>> Best,
>>>>>> Alex.
>>>>>
>>>
>>>
>>>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [QVTO] Implicit source vs contextless invocation [message #72592 is a reply to message #72538] Fri, 18 January 2008 13:50 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Alexander.Igdalov.borland.com

Hi Adolfo,

Thanks for your comment. I share most of your ideas but I doubt that
contextless mappings without parameters have no sense. They create a
record in the trace which can be later used in update mode. In case of a
mapping, the result object will not be re-created but will be taken from
the trace obtained on the first-run step. Thus, this is not an
equivalent to a simple constructor. Moreover, as I've mentioned in my
reply to Sergey, such a mapping is used in one of the QVT spec samples
("A.2.4 SPEM UML Profile to SPEM metamodel" on p. 176).

Best wishes,
Alex.

Adolfo Sánchez-Barbudo Herrera wrote:
> Hi all,
>
> > var d := Sequence { object EClass { name := 'a'},
> > object EClass { name := 'b'}};
> > var e := d->collect(map a());
>
> Well in this case, the Sequence is defined as a Sequence whose objects
> are of type EClass, so when collecting over the variable 'd' the
> expression refers to the objects of the collection, therefore the
> EClass:a mapping should be implicitly invoked...
>
> This equivalent expression perhaps could help...
>
> var e := d->collect(aVariable : EClass | aVariable.map a());
>
> Besides, as Sergey comments, a non-contextual mapping without parameters
> should not be allowed, since it doesn't make sense.
>
> The Sergey's case where you can define a non-contextual mapping with a
> parameter, whose type is the context of another contextual mapping
> without parameters, is dangerous (and ambiguous) because we have 2
> different mappings implemented for the same purposes (Work on the same
> element)...It could seem that both mapping could differenced when
> invoking them, but since the contextual parameter can be established as
> the first argument of the mapping call expression (and not having a
> source for the MCE), this differentiation is not possible. So i think
> that 2 actions could be taken:
>
> 1. Throw an error, as you would have declared the same mapping twice.
> 2. Consider that the contextual mapping is the correct, and throw a
> warning indicating that the non-contextual mapping will never be executed.
>
> The second is the action that I'm taking. I know that the specification
> haven't concerned/realized about this kind of problems, but this kind of
> work would help to specifications to be refined/clarified/improved.
>
> Best Regards,
> Adolfo.
>
> Alexander Igdalov escribió:
>> Radek Dvorak wrote:
>>> On Thu, 17 Jan 2008 12:24:11 +0100, Alexander Igdalov
>>> <Alexander.Igdalov@borland.com> wrote:
>>>
>>>> Hi Radek,
>>>>
>>>> My comments are below.
>>>>
>>>> Radek Dvorak wrote:
>>>>> Hi Alex,
>>>>> I have inlined some comments bellow.
>>>>> Regards,
>>>>> /Radek
>>>>> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov
>>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Operational QVT enables to write some constructions with and
>>>>>> without context. These are mappings and resolveIn expressions. For
>>>>>> instance, one can define two mappings
>>>>>>
>>>>>> mapping EClass::a() : EClass {
>>>>>> name := 'a-context';
>>>>>> }
>>>>>>
>>>>>> mapping a() : EClass {
>>>>>> name := 'a-contextless';
>>>>>> }
>>>>>>
>>>>>> And invoke them this way:
>>>>>>
>>>>>> myClass.map a(); -- first mapping
>>>>>> map a(); -- second mapping
>>>>>>
>>>>>> The following ambiguity is not resolved in the spec. How should
>>>>>> the QVT engine behave in case of implicit variables in the
>>>>>> environment.
>>>>>>
>>>>>> Sample:
>>>>>>
>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>> object EClass { name := 'b'}};
>>>>>> var e := d->collect(map a());
>>>>>>
>>>>>> In this case there is an implicit iterator of the 'collect'
>>>>>> expression. That's why 'mapping EClass::a() : EClass' is to be
>>>>>> called. On the other hand, there is a contextless version of
>>>>>> mapping a(). Therefore, 'mapping a() : EClass' is to be called.
>>>>>> The question is which mapping is more preferrable? Or make it a
>>>>>> compiler error/warning requiring the user to change mapping names?
>>>>> This ambiguity is solved by OCL spec, so collect should take the
>>>>> most inner scope first,
>>>>> in which case it resolves to 'mapping EClass::a() : EClass' as the
>>>>> implicit iterator variable
>>>>> is of type EClass.
>>>>
>>>> That is good if the spec is clear about it. But where exactly is
>>>> this done?
>>>
>>> See OCL spec, 7.8 Resolving Properties
>>>
>>
>> To my mind, this section is about the priority of implicit variables
>> in case the source is expected. In other words, the section just says
>> that the most inner scope implicit variables are preferred to implicit
>> variables of other scopes. However, it doesn't state what to do in
>> case when there are operations without source.
>>
>>>>
>>>>> As QVT claims to extend OCL, though it's not completely true:), in
>>>>> this case it
>>>>> should execute the same.
>>>>> Provided that the above contextual mapping for EClass is already
>>>>> defined, a mapping of the signature
>>>>> bellow should not be allowed and compilation error produced.
>>>>> mapping a(in EClass);
>>>>> The reason is that the first contextual definition introduces also
>>>>> the non-contextual variant into the
>>>>> namespace of the defining transformation.
>>>>
>>>> Could you prove it, too?
>>>
>>> Not sure what kind of proof you expect ;-) but the following sections
>>> worked for me:
>>> QVT spec, 8.2.1.10 ImperativeOperation and 8.2.1.21 MappingCallExp.
>>>
>>
>> I expect some phrase from the spec saying that 'mapping EClass::a()'
>> introduces 'mapping a(in EClass)' as well;-)
>>
>>>>
>>>>>
>>>>>>
>>>>>> When it comes to resolveIn expressions the situation is even
>>>>>> worse, since 'this' in transformations is always implicit:
>>>>>>
>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>> object EClass { name := 'b'}};
>>>>>> var f := d->collect(resolveIn(EClass::a, EClass));
>>>>>>
>>>>>> What should be used here: sourceless resolveIn or resolveIn on
>>>>>> 'collect' iterator? Apart from collect exps, in case of simple
>>>>>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used
>>>>>> or should it be resolveIn on 'this'?
>>>>> I think, 8.1.16 section of the QVT spec could be used to solve
>>>>> this problem.
>>>>> It states that 'this' can be used implicitly with transformation
>>>>> properties, operations,
>>>>> which 'resolveIn' is not.
>>>>> To be consistent with what I have said above, 'resolveIn' used in
>>>>> colllect should resolve to the iterator variable
>>>>> as the source.
>>>>> In case the most inner scope would be a transformation, 'resolveIn'
>>>>> is without source, as
>>>>> it should not be used with implicit 'this' and executes according
>>>>> to optional source semantics
>>>>> of ResolveInExp, 8.2.1.23.
>>>>>
>>>>>>
>>>>>> Your thoughts, please?
>>>>>>
>>>>>> Best,
>>>>>> Alex.
>>>>>
>>>
>>>
>>>
Re: [QVTO] Implicit source vs contextless invocation [message #72608 is a reply to message #72574] Fri, 18 January 2008 14:37 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: research.opencanarias.com

Radek Dvorak escribió:
> Hi Adolfo,
>
> If taking the action 2), I just wonder how you handle a call written as
> bellow:
>
> var eClass : EClass := ...;
>
> this.map a(eClass); -- provided that mapping EClass::a(); mapping a(in
> c:EClass); definitions are allowed
>
> Would this call expression be allowed?

Yes it should. The following expressions (for instance, in the main
entry operation)

this.map a(eClass);
map a(eClass);
eClass.map a();

are all the same MappingCallExpression, and they should refers to the
contextual mapping operation. As i mentioned is a personal decision that
i have taken (is not deducted from specification) the other related to
mark two errors in both operation mapping definitions could be valid too
;). Anyway the spec should clarify what decision we should take in all
kind of issues.

About my solution: I suggest, instead of not compiling the
transformation, taking the following actions:
- Mark a warning over the non-contextual mapping.
- Every MCE should refers to the contextual one.

I don't remember (i'll take a look) the process I'm taking when i
resolve the lookup of the MappingOperation (in the MCE), but if i
maintain the non-contextual operation in the output model, symbol's
table, etc I must ensure that the lookup of the MappingOperation returns
the contextual one.


> AFAIU, you allow both definitions contextual, non-contextual and the
> warning is targeted to the non-contextual def.
> as the never executed one.
>
> Regards,
> /Radek
>
>
> On Fri, 18 Jan 2008 13:44:13 +0100, Adolfo Sánchez-Barbudo Herrera
> <research@opencanarias.com> wrote:
>
>> Hi all,
>>
>> > var d := Sequence { object EClass { name := 'a'},
>> > object EClass { name := 'b'}};
>> > var e := d->collect(map a());
>>
>> Well in this case, the Sequence is defined as a Sequence whose objects
>> are of type EClass, so when collecting over the variable 'd' the
>> expression refers to the objects of the collection, therefore the
>> EClass:a mapping should be implicitly invoked...
>>
>> This equivalent expression perhaps could help...
>>
>> var e := d->collect(aVariable : EClass | aVariable.map a());
>>
>> Besides, as Sergey comments, a non-contextual mapping without
>> parameters should not be allowed, since it doesn't make sense.
>>
>> The Sergey's case where you can define a non-contextual mapping with a
>> parameter, whose type is the context of another contextual mapping
>> without parameters, is dangerous (and ambiguous) because we have 2
>> different mappings implemented for the same purposes (Work on the same
>> element)...It could seem that both mapping could differenced when
>> invoking them, but since the contextual parameter can be established
>> as the first argument of the mapping call expression (and not having a
>> source for the MCE), this differentiation is not possible. So i think
>> that 2 actions could be taken:
>>
>> 1. Throw an error, as you would have declared the same mapping twice.
>> 2. Consider that the contextual mapping is the correct, and throw a
>> warning indicating that the non-contextual mapping will never be
>> executed.
>>
>> The second is the action that I'm taking. I know that the
>> specification haven't concerned/realized about this kind of problems,
>> but this kind of work would help to specifications to be
>> refined/clarified/improved.
>>
>> Best Regards,
>> Adolfo.
>>
>> Alexander Igdalov escribió:
>>> Radek Dvorak wrote:
>>>> On Thu, 17 Jan 2008 12:24:11 +0100, Alexander Igdalov
>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>
>>>>> Hi Radek,
>>>>>
>>>>> My comments are below.
>>>>>
>>>>> Radek Dvorak wrote:
>>>>>> Hi Alex,
>>>>>> I have inlined some comments bellow.
>>>>>> Regards,
>>>>>> /Radek
>>>>>> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov
>>>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Operational QVT enables to write some constructions with and
>>>>>>> without context. These are mappings and resolveIn expressions.
>>>>>>> For instance, one can define two mappings
>>>>>>>
>>>>>>> mapping EClass::a() : EClass {
>>>>>>> name := 'a-context';
>>>>>>> }
>>>>>>>
>>>>>>> mapping a() : EClass {
>>>>>>> name := 'a-contextless';
>>>>>>> }
>>>>>>>
>>>>>>> And invoke them this way:
>>>>>>>
>>>>>>> myClass.map a(); -- first mapping
>>>>>>> map a(); -- second mapping
>>>>>>>
>>>>>>> The following ambiguity is not resolved in the spec. How should
>>>>>>> the QVT engine behave in case of implicit variables in the
>>>>>>> environment.
>>>>>>>
>>>>>>> Sample:
>>>>>>>
>>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>>> object EClass { name := 'b'}};
>>>>>>> var e := d->collect(map a());
>>>>>>>
>>>>>>> In this case there is an implicit iterator of the 'collect'
>>>>>>> expression. That's why 'mapping EClass::a() : EClass' is to be
>>>>>>> called. On the other hand, there is a contextless version of
>>>>>>> mapping a(). Therefore, 'mapping a() : EClass' is to be called.
>>>>>>> The question is which mapping is more preferrable? Or make it a
>>>>>>> compiler error/warning requiring the user to change mapping names?
>>>>>> This ambiguity is solved by OCL spec, so collect should take the
>>>>>> most inner scope first,
>>>>>> in which case it resolves to 'mapping EClass::a() : EClass' as the
>>>>>> implicit iterator variable
>>>>>> is of type EClass.
>>>>>
>>>>> That is good if the spec is clear about it. But where exactly is
>>>>> this done?
>>>>
>>>> See OCL spec, 7.8 Resolving Properties
>>>>
>>> To my mind, this section is about the priority of implicit variables
>>> in case the source is expected. In other words, the section just says
>>> that the most inner scope implicit variables are preferred to
>>> implicit variables of other scopes. However, it doesn't state what to
>>> do in case when there are operations without source.
>>>
>>>>>
>>>>>> As QVT claims to extend OCL, though it's not completely true:), in
>>>>>> this case it
>>>>>> should execute the same.
>>>>>> Provided that the above contextual mapping for EClass is already
>>>>>> defined, a mapping of the signature
>>>>>> bellow should not be allowed and compilation error produced.
>>>>>> mapping a(in EClass);
>>>>>> The reason is that the first contextual definition introduces
>>>>>> also the non-contextual variant into the
>>>>>> namespace of the defining transformation.
>>>>>
>>>>> Could you prove it, too?
>>>>
>>>> Not sure what kind of proof you expect ;-) but the following
>>>> sections worked for me:
>>>> QVT spec, 8.2.1.10 ImperativeOperation and 8.2.1.21 MappingCallExp.
>>>>
>>> I expect some phrase from the spec saying that 'mapping EClass::a()'
>>> introduces 'mapping a(in EClass)' as well;-)
>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> When it comes to resolveIn expressions the situation is even
>>>>>>> worse, since 'this' in transformations is always implicit:
>>>>>>>
>>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>>> object EClass { name := 'b'}};
>>>>>>> var f := d->collect(resolveIn(EClass::a, EClass));
>>>>>>>
>>>>>>> What should be used here: sourceless resolveIn or resolveIn on
>>>>>>> 'collect' iterator? Apart from collect exps, in case of simple
>>>>>>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be
>>>>>>> used or should it be resolveIn on 'this'?
>>>>>> I think, 8.1.16 section of the QVT spec could be used to solve
>>>>>> this problem.
>>>>>> It states that 'this' can be used implicitly with transformation
>>>>>> properties, operations,
>>>>>> which 'resolveIn' is not.
>>>>>> To be consistent with what I have said above, 'resolveIn' used in
>>>>>> colllect should resolve to the iterator variable
>>>>>> as the source.
>>>>>> In case the most inner scope would be a transformation,
>>>>>> 'resolveIn' is without source, as
>>>>>> it should not be used with implicit 'this' and executes according
>>>>>> to optional source semantics
>>>>>> of ResolveInExp, 8.2.1.23.
>>>>>>
>>>>>>>
>>>>>>> Your thoughts, please?
>>>>>>>
>>>>>>> Best,
>>>>>>> Alex.
>>>>>>
>>>>
>>>>
>>>>
>
>
>
Re: [QVTO] Implicit source vs contextless invocation [message #72654 is a reply to message #72592] Fri, 18 January 2008 15:17 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: research.opencanarias.com

Hi Alex,

Although i thought in mappings without every kind of parameters
(including the result one), i didn't get the case that you mention. When
i want to create objects i naturally think in the use of the object
expression... But combining a mapping parameter with a resolveInExp in
order to get the same object creating it only one time, is a good idea ;).

Thanks for the aclaration ;)

Anyway the existence or none of a result parameter for the mapping
parameter, should not be relevant for the MappingCallExpression.

I think that your question could be answered viewing from this point of
view...

Does it make sense executing a non-contextual mapping if the
correspondent MCE has a source?. I think that it doesn't, because you
would be computing a lot of stuff that it would be useful for the MCE.

I think that if we have a source for MCE, a contextual mapping operation
should be used, and probably an error detected if the MCE just matches
with a non-contextual mapping operation...Anyway, I'll take a new review
to the spec, to see if i could get some contradiction to this unsure
"affirmation".

Cheers,
Adolfo.

Alexander Igdalov escribió:
> Hi Adolfo,
>
> Thanks for your comment. I share most of your ideas but I doubt that
> contextless mappings without parameters have no sense. They create a
> record in the trace which can be later used in update mode. In case of a
> mapping, the result object will not be re-created but will be taken from
> the trace obtained on the first-run step. Thus, this is not an
> equivalent to a simple constructor. Moreover, as I've mentioned in my
> reply to Sergey, such a mapping is used in one of the QVT spec samples
> ("A.2.4 SPEM UML Profile to SPEM metamodel" on p. 176).
>
> Best wishes,
> Alex.
>
> Adolfo Sánchez-Barbudo Herrera wrote:
>> Hi all,
>>
>> > var d := Sequence { object EClass { name := 'a'},
>> > object EClass { name := 'b'}};
>> > var e := d->collect(map a());
>>
>> Well in this case, the Sequence is defined as a Sequence whose objects
>> are of type EClass, so when collecting over the variable 'd' the
>> expression refers to the objects of the collection, therefore the
>> EClass:a mapping should be implicitly invoked...
>>
>> This equivalent expression perhaps could help...
>>
>> var e := d->collect(aVariable : EClass | aVariable.map a());
>>
>> Besides, as Sergey comments, a non-contextual mapping without
>> parameters should not be allowed, since it doesn't make sense.
>>
>> The Sergey's case where you can define a non-contextual mapping with a
>> parameter, whose type is the context of another contextual mapping
>> without parameters, is dangerous (and ambiguous) because we have 2
>> different mappings implemented for the same purposes (Work on the same
>> element)...It could seem that both mapping could differenced when
>> invoking them, but since the contextual parameter can be established
>> as the first argument of the mapping call expression (and not having a
>> source for the MCE), this differentiation is not possible. So i think
>> that 2 actions could be taken:
>>
>> 1. Throw an error, as you would have declared the same mapping twice.
>> 2. Consider that the contextual mapping is the correct, and throw a
>> warning indicating that the non-contextual mapping will never be
>> executed.
>>
>> The second is the action that I'm taking. I know that the
>> specification haven't concerned/realized about this kind of problems,
>> but this kind of work would help to specifications to be
>> refined/clarified/improved.
>>
>> Best Regards,
>> Adolfo.
>>
>> Alexander Igdalov escribió:
>>> Radek Dvorak wrote:
>>>> On Thu, 17 Jan 2008 12:24:11 +0100, Alexander Igdalov
>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>
>>>>> Hi Radek,
>>>>>
>>>>> My comments are below.
>>>>>
>>>>> Radek Dvorak wrote:
>>>>>> Hi Alex,
>>>>>> I have inlined some comments bellow.
>>>>>> Regards,
>>>>>> /Radek
>>>>>> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov
>>>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Operational QVT enables to write some constructions with and
>>>>>>> without context. These are mappings and resolveIn expressions.
>>>>>>> For instance, one can define two mappings
>>>>>>>
>>>>>>> mapping EClass::a() : EClass {
>>>>>>> name := 'a-context';
>>>>>>> }
>>>>>>>
>>>>>>> mapping a() : EClass {
>>>>>>> name := 'a-contextless';
>>>>>>> }
>>>>>>>
>>>>>>> And invoke them this way:
>>>>>>>
>>>>>>> myClass.map a(); -- first mapping
>>>>>>> map a(); -- second mapping
>>>>>>>
>>>>>>> The following ambiguity is not resolved in the spec. How should
>>>>>>> the QVT engine behave in case of implicit variables in the
>>>>>>> environment.
>>>>>>>
>>>>>>> Sample:
>>>>>>>
>>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>>> object EClass { name := 'b'}};
>>>>>>> var e := d->collect(map a());
>>>>>>>
>>>>>>> In this case there is an implicit iterator of the 'collect'
>>>>>>> expression. That's why 'mapping EClass::a() : EClass' is to be
>>>>>>> called. On the other hand, there is a contextless version of
>>>>>>> mapping a(). Therefore, 'mapping a() : EClass' is to be called.
>>>>>>> The question is which mapping is more preferrable? Or make it a
>>>>>>> compiler error/warning requiring the user to change mapping names?
>>>>>> This ambiguity is solved by OCL spec, so collect should take the
>>>>>> most inner scope first,
>>>>>> in which case it resolves to 'mapping EClass::a() : EClass' as the
>>>>>> implicit iterator variable
>>>>>> is of type EClass.
>>>>>
>>>>> That is good if the spec is clear about it. But where exactly is
>>>>> this done?
>>>>
>>>> See OCL spec, 7.8 Resolving Properties
>>>>
>>>
>>> To my mind, this section is about the priority of implicit variables
>>> in case the source is expected. In other words, the section just says
>>> that the most inner scope implicit variables are preferred to
>>> implicit variables of other scopes. However, it doesn't state what to
>>> do in case when there are operations without source.
>>>
>>>>>
>>>>>> As QVT claims to extend OCL, though it's not completely true:), in
>>>>>> this case it
>>>>>> should execute the same.
>>>>>> Provided that the above contextual mapping for EClass is already
>>>>>> defined, a mapping of the signature
>>>>>> bellow should not be allowed and compilation error produced.
>>>>>> mapping a(in EClass);
>>>>>> The reason is that the first contextual definition introduces
>>>>>> also the non-contextual variant into the
>>>>>> namespace of the defining transformation.
>>>>>
>>>>> Could you prove it, too?
>>>>
>>>> Not sure what kind of proof you expect ;-) but the following
>>>> sections worked for me:
>>>> QVT spec, 8.2.1.10 ImperativeOperation and 8.2.1.21 MappingCallExp.
>>>>
>>>
>>> I expect some phrase from the spec saying that 'mapping EClass::a()'
>>> introduces 'mapping a(in EClass)' as well;-)
>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> When it comes to resolveIn expressions the situation is even
>>>>>>> worse, since 'this' in transformations is always implicit:
>>>>>>>
>>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>>> object EClass { name := 'b'}};
>>>>>>> var f := d->collect(resolveIn(EClass::a, EClass));
>>>>>>>
>>>>>>> What should be used here: sourceless resolveIn or resolveIn on
>>>>>>> 'collect' iterator? Apart from collect exps, in case of simple
>>>>>>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be
>>>>>>> used or should it be resolveIn on 'this'?
>>>>>> I think, 8.1.16 section of the QVT spec could be used to solve
>>>>>> this problem.
>>>>>> It states that 'this' can be used implicitly with transformation
>>>>>> properties, operations,
>>>>>> which 'resolveIn' is not.
>>>>>> To be consistent with what I have said above, 'resolveIn' used in
>>>>>> colllect should resolve to the iterator variable
>>>>>> as the source.
>>>>>> In case the most inner scope would be a transformation,
>>>>>> 'resolveIn' is without source, as
>>>>>> it should not be used with implicit 'this' and executes according
>>>>>> to optional source semantics
>>>>>> of ResolveInExp, 8.2.1.23.
>>>>>>
>>>>>>>
>>>>>>> Your thoughts, please?
>>>>>>>
>>>>>>> Best,
>>>>>>> Alex.
>>>>>>
>>>>
>>>>
>>>>
Re: [QVTO] Implicit source vs contextless invocation [message #72668 is a reply to message #72654] Fri, 18 January 2008 15:55 Go to previous messageGo to next message
Sergey Boyko is currently offline Sergey BoykoFriend
Messages: 171
Registered: July 2009
Senior Member
Hi Adolfo,

According to spec, section 8.2.1.15 MappingOperation:
"Executing a mapping operation

If the guard succeeds, the relation trace is checked to find out whether
the relation already holds. If so, the out
parameters are populated using the corresponding trace tuples of the
relation and the value associated to the result
parameters is returned. Otherwise the body of the operation is executed
in three sections."

It means that contextless mapping without parameters is definitely
singleton with no exception since on second and subsequent executions
even init{} section is not performed and the same object is always
returned.
That singleton behavior is mapping only inhered and in this sense such
mapping is useful. However example mapping that Alex referred is
somewhat odd, we never execute it's init {} section twice.


I also vote for prefer context mapping to contextless one.
In case of ambiguity declaration when user explicitly defines

mapping EClass::a() : EClass {}
and
mapping a(in eCls : EClass) : EClass {}

second declaration should be marked with warning as hided by context
version of the mapping.

However if only second declaration is present use definitely should be
allowed to call it.


Regards,
Sergey.


> Hi Alex,
>
> Although i thought in mappings without every kind of parameters
> (including the result one), i didn't get the case that you mention. When
> i want to create objects i naturally think in the use of the object
> expression... But combining a mapping parameter with a resolveInExp in
> order to get the same object creating it only one time, is a good idea ;).
>
> Thanks for the aclaration ;)
>
> Anyway the existence or none of a result parameter for the mapping
> parameter, should not be relevant for the MappingCallExpression.
>
> I think that your question could be answered viewing from this point of
> view...
>
> Does it make sense executing a non-contextual mapping if the
> correspondent MCE has a source?. I think that it doesn't, because you
> would be computing a lot of stuff that it would be useful for the MCE.
>
> I think that if we have a source for MCE, a contextual mapping operation
> should be used, and probably an error detected if the MCE just matches
> with a non-contextual mapping operation...Anyway, I'll take a new review
> to the spec, to see if i could get some contradiction to this unsure
> "affirmation".
>
> Cheers,
> Adolfo.
>
> Alexander Igdalov escribió:
>> Hi Adolfo,
>>
>> Thanks for your comment. I share most of your ideas but I doubt that
>> contextless mappings without parameters have no sense. They create a
>> record in the trace which can be later used in update mode. In case of
>> a mapping, the result object will not be re-created but will be taken
>> from the trace obtained on the first-run step. Thus, this is not an
>> equivalent to a simple constructor. Moreover, as I've mentioned in my
>> reply to Sergey, such a mapping is used in one of the QVT spec samples
>> ("A.2.4 SPEM UML Profile to SPEM metamodel" on p. 176).
>>
>> Best wishes,
>> Alex.
>>
Re: [QVTO] Implicit source vs contextless invocation [message #72696 is a reply to message #72608] Fri, 18 January 2008 16:03 Go to previous messageGo to next message
Radomil Dvorak is currently offline Radomil DvorakFriend
Messages: 249
Registered: July 2009
Senior Member
Some comments inlined.

On Fri, 18 Jan 2008 15:37:20 +0100, Adolfo Sánchez-Barbudo Herrera
<research@opencanarias.com> wrote:

>
> Radek Dvorak escribió:
>> Hi Adolfo,
>> If taking the action 2), I just wonder how you handle a call written
>> as bellow:
>> var eClass : EClass := ...;
>> this.map a(eClass); -- provided that mapping EClass::a(); mapping a(in
>> c:EClass); definitions are allowed
>> Would this call expression be allowed?
>
> Yes it should. The following expressions (for instance, in the main
> entry operation)
>
> this.map a(eClass);
> map a(eClass);
> eClass.map a();
>
> are all the same MappingCallExpression, and they should refers to the
> contextual mapping operation. As i mentioned is a personal decision that
> i have taken (is not deducted from specification) the other related to
> mark two errors in both operation mapping definitions could be valid too
> ;). Anyway the spec should clarify what decision we should take in all
> kind of issues.

Yeah, such a personal decision ;-) is sometimes the spice of dealing with
QVT.

My personal preference would be a compilation error ;-)
The reason why is what happens if the contextual operation gets
removed. I guess, the call 'this.map a(eClass)' would silently resolve to
the remaining
non-contextual operation defined 'explicitly', marked as never executed
till this time.
So by this removal I might change the implementation nearly unnoticeably.
Then choosing 1) option might only disallow to define what is not callable.

I agree, the same damage I may cause other way, like removing an operation
that overrides
another.

Another interesting problem about the implicit source resolution is
with ResolveInExp, as the spec states it is optional.
What kind of decision have you taken here? ;-)
I have outlined my understaning of the spec in this thread,
but seems not convincing for Alex.


>
> About my solution: I suggest, instead of not compiling the
> transformation, taking the following actions:
> - Mark a warning over the non-contextual mapping.
> - Every MCE should refers to the contextual one.
>
> I don't remember (i'll take a look) the process I'm taking when i
> resolve the lookup of the MappingOperation (in the MCE), but if i
> maintain the non-contextual operation in the output model, symbol's
> table, etc I must ensure that the lookup of the MappingOperation returns
> the contextual one.
>
>
>> AFAIU, you allow both definitions contextual, non-contextual and the
>> warning is targeted to the non-contextual def.
>> as the never executed one.
>> Regards,
>> /Radek
>> On Fri, 18 Jan 2008 13:44:13 +0100, Adolfo Sánchez-Barbudo Herrera
>> <research@opencanarias.com> wrote:
>>
>>> Hi all,
>>>
>>> > var d := Sequence { object EClass { name := 'a'},
>>> > object EClass { name := 'b'}};
>>> > var e := d->collect(map a());
>>>
>>> Well in this case, the Sequence is defined as a Sequence whose objects
>>> are of type EClass, so when collecting over the variable 'd' the
>>> expression refers to the objects of the collection, therefore the
>>> EClass:a mapping should be implicitly invoked...
>>>
>>> This equivalent expression perhaps could help...
>>>
>>> var e := d->collect(aVariable : EClass | aVariable.map a());
>>>
>>> Besides, as Sergey comments, a non-contextual mapping without
>>> parameters should not be allowed, since it doesn't make sense.
>>>
>>> The Sergey's case where you can define a non-contextual mapping with a
>>> parameter, whose type is the context of another contextual mapping
>>> without parameters, is dangerous (and ambiguous) because we have 2
>>> different mappings implemented for the same purposes (Work on the same
>>> element)...It could seem that both mapping could differenced when
>>> invoking them, but since the contextual parameter can be established
>>> as the first argument of the mapping call expression (and not having a
>>> source for the MCE), this differentiation is not possible. So i think
>>> that 2 actions could be taken:
>>>
>>> 1. Throw an error, as you would have declared the same mapping twice.
>>> 2. Consider that the contextual mapping is the correct, and throw a
>>> warning indicating that the non-contextual mapping will never be
>>> executed.
>>>
>>> The second is the action that I'm taking. I know that the
>>> specification haven't concerned/realized about this kind of problems,
>>> but this kind of work would help to specifications to be
>>> refined/clarified/improved.
>>>
>>> Best Regards,
>>> Adolfo.
>>>
>>> Alexander Igdalov escribió:
>>>> Radek Dvorak wrote:
>>>>> On Thu, 17 Jan 2008 12:24:11 +0100, Alexander Igdalov
>>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>>
>>>>>> Hi Radek,
>>>>>>
>>>>>> My comments are below.
>>>>>>
>>>>>> Radek Dvorak wrote:
>>>>>>> Hi Alex,
>>>>>>> I have inlined some comments bellow.
>>>>>>> Regards,
>>>>>>> /Radek
>>>>>>> On Wed, 16 Jan 2008 17:07:51 +0100, Alexander Igdalov
>>>>>>> <Alexander.Igdalov@borland.com> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Operational QVT enables to write some constructions with and
>>>>>>>> without context. These are mappings and resolveIn expressions.
>>>>>>>> For instance, one can define two mappings
>>>>>>>>
>>>>>>>> mapping EClass::a() : EClass {
>>>>>>>> name := 'a-context';
>>>>>>>> }
>>>>>>>>
>>>>>>>> mapping a() : EClass {
>>>>>>>> name := 'a-contextless';
>>>>>>>> }
>>>>>>>>
>>>>>>>> And invoke them this way:
>>>>>>>>
>>>>>>>> myClass.map a(); -- first mapping
>>>>>>>> map a(); -- second mapping
>>>>>>>>
>>>>>>>> The following ambiguity is not resolved in the spec. How should
>>>>>>>> the QVT engine behave in case of implicit variables in the
>>>>>>>> environment.
>>>>>>>>
>>>>>>>> Sample:
>>>>>>>>
>>>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>>>> object EClass { name := 'b'}};
>>>>>>>> var e := d->collect(map a());
>>>>>>>>
>>>>>>>> In this case there is an implicit iterator of the 'collect'
>>>>>>>> expression. That's why 'mapping EClass::a() : EClass' is to be
>>>>>>>> called. On the other hand, there is a contextless version of
>>>>>>>> mapping a(). Therefore, 'mapping a() : EClass' is to be called.
>>>>>>>> The question is which mapping is more preferrable? Or make it a
>>>>>>>> compiler error/warning requiring the user to change mapping names?
>>>>>>> This ambiguity is solved by OCL spec, so collect should take the
>>>>>>> most inner scope first,
>>>>>>> in which case it resolves to 'mapping EClass::a() : EClass' as the
>>>>>>> implicit iterator variable
>>>>>>> is of type EClass.
>>>>>>
>>>>>> That is good if the spec is clear about it. But where exactly is
>>>>>> this done?
>>>>>
>>>>> See OCL spec, 7.8 Resolving Properties
>>>>>
>>>> To my mind, this section is about the priority of implicit variables
>>>> in case the source is expected. In other words, the section just says
>>>> that the most inner scope implicit variables are preferred to
>>>> implicit variables of other scopes. However, it doesn't state what to
>>>> do in case when there are operations without source.
>>>>
>>>>>>
>>>>>>> As QVT claims to extend OCL, though it's not completely true:), in
>>>>>>> this case it
>>>>>>> should execute the same.
>>>>>>> Provided that the above contextual mapping for EClass is already
>>>>>>> defined, a mapping of the signature
>>>>>>> bellow should not be allowed and compilation error produced.
>>>>>>> mapping a(in EClass);
>>>>>>> The reason is that the first contextual definition introduces
>>>>>>> also the non-contextual variant into the
>>>>>>> namespace of the defining transformation.
>>>>>>
>>>>>> Could you prove it, too?
>>>>>
>>>>> Not sure what kind of proof you expect ;-) but the following
>>>>> sections worked for me:
>>>>> QVT spec, 8.2.1.10 ImperativeOperation and 8.2.1.21 MappingCallExp.
>>>>>
>>>> I expect some phrase from the spec saying that 'mapping EClass::a()'
>>>> introduces 'mapping a(in EClass)' as well;-)
>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> When it comes to resolveIn expressions the situation is even
>>>>>>>> worse, since 'this' in transformations is always implicit:
>>>>>>>>
>>>>>>>> var d := Sequence { object EClass { name := 'a'},
>>>>>>>> object EClass { name := 'b'}};
>>>>>>>> var f := d->collect(resolveIn(EClass::a, EClass));
>>>>>>>>
>>>>>>>> What should be used here: sourceless resolveIn or resolveIn on
>>>>>>>> 'collect' iterator? Apart from collect exps, in case of simple
>>>>>>>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be
>>>>>>>> used or should it be resolveIn on 'this'?
>>>>>>> I think, 8.1.16 section of the QVT spec could be used to solve
>>>>>>> this problem.
>>>>>>> It states that 'this' can be used implicitly with transformation
>>>>>>> properties, operations,
>>>>>>> which 'resolveIn' is not.
>>>>>>> To be consistent with what I have said above, 'resolveIn' used in
>>>>>>> colllect should resolve to the iterator variable
>>>>>>> as the source.
>>>>>>> In case the most inner scope would be a transformation,
>>>>>>> 'resolveIn' is without source, as
>>>>>>> it should not be used with implicit 'this' and executes according
>>>>>>> to optional source semantics
>>>>>>> of ResolveInExp, 8.2.1.23.
>>>>>>>
>>>>>>>>
>>>>>>>> Your thoughts, please?
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Alex.
>>>>>>>
>>>>>
>>>>>
>>>>>
>>



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Re: [QVTO] Implicit source vs contextless invocation [message #72708 is a reply to message #72668] Fri, 18 January 2008 16:30 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: Alexander.Igdalov.borland.com

Sergey Boyko wrote:
> Hi Adolfo,
>
> According to spec, section 8.2.1.15 MappingOperation:
> "Executing a mapping operation
>
> If the guard succeeds, the relation trace is checked to find out whether
> the relation already holds. If so, the out
> parameters are populated using the corresponding trace tuples of the
> relation and the value associated to the result
> parameters is returned. Otherwise the body of the operation is executed
> in three sections."
>
> It means that contextless mapping without parameters is definitely
> singleton with no exception since on second and subsequent executions
> even init{} section is not performed and the same object is always
> returned.
> That singleton behavior is mapping only inhered and in this sense such
> mapping is useful. However example mapping that Alex referred is
> somewhat odd, we never execute it's init {} section twice.
>
>

The sample has a really strange implementation though it has a good idea
in it (a singleton pattern). The init-section of the mapping seems to be
redundant. I think it starts to play its role in the update-mode only.
However, I do not think that it was intended originally by the spec writers.

> I also vote for prefer context mapping to contextless one.
> In case of ambiguity declaration when user explicitly defines
>
> mapping EClass::a() : EClass {}
> and
> mapping a(in eCls : EClass) : EClass {}
>
> second declaration should be marked with warning as hided by context
> version of the mapping.
>
> However if only second declaration is present use definitely should be
> allowed to call it.
>
>
> Regards,
> Sergey.
>
>
>> Hi Alex,
>>
>> Although i thought in mappings without every kind of parameters
>> (including the result one), i didn't get the case that you mention.
>> When i want to create objects i naturally think in the use of the
>> object expression... But combining a mapping parameter with a
>> resolveInExp in order to get the same object creating it only one
>> time, is a good idea ;).
>>
>> Thanks for the aclaration ;)
>>
>> Anyway the existence or none of a result parameter for the mapping
>> parameter, should not be relevant for the MappingCallExpression.
>>
>> I think that your question could be answered viewing from this point
>> of view...
>>
>> Does it make sense executing a non-contextual mapping if the
>> correspondent MCE has a source?. I think that it doesn't, because you
>> would be computing a lot of stuff that it would be useful for the MCE.
>>
>> I think that if we have a source for MCE, a contextual mapping
>> operation should be used, and probably an error detected if the MCE
>> just matches with a non-contextual mapping operation...Anyway, I'll
>> take a new review to the spec, to see if i could get some
>> contradiction to this unsure "affirmation".
>>
>> Cheers,
>> Adolfo.
>>
>> Alexander Igdalov escribió:
>>> Hi Adolfo,
>>>
>>> Thanks for your comment. I share most of your ideas but I doubt that
>>> contextless mappings without parameters have no sense. They create a
>>> record in the trace which can be later used in update mode. In case
>>> of a mapping, the result object will not be re-created but will be
>>> taken from the trace obtained on the first-run step. Thus, this is
>>> not an equivalent to a simple constructor. Moreover, as I've
>>> mentioned in my reply to Sergey, such a mapping is used in one of
>>> the QVT spec samples ("A.2.4 SPEM UML Profile to SPEM metamodel" on
>>> p. 176).
>>>
>>> Best wishes,
>>> Alex.
>>>
Re: [QVTO] Implicit source vs contextless invocation [message #73214 is a reply to message #72220] Thu, 24 January 2008 11:04 Go to previous message
Eclipse UserFriend
Originally posted by: Alexander.Igdalov.borland.com

Hi Sergey,

AFAIU, you say that `this` cannot be mapped because you cannot invoke
mappings defined with Module as the context. Consider a mapping

mapping EClass::transfMapping(in param : EPackage) : EPackage {}

Since Module is EClass we might wish to invoke transfMapping on `this`.
The notation `this.map transfMapping(pack)` is a synonym of `pack.map
transfMapping()`. Thus, you believe that the mapping above cannot be called.

This point is arguable since we have the ambiguity only if `mapping
EPackage::transfMapping()` is defined. If not there is no problem in
guessing what to call. What's more, you can always invoke the mapping
using the ownership approach: `this.map transfMapping(this, pack)`.

If `this` is allowed to be mapped why not to use it in resolve
expressions. Thus, `this.resolve()` would stand for a search for target
objects for `this`.

Further on this, as Radek has mentioned according to the spec "'this'
can be used implicitly with transformation properties, operations, which
'resolveIn' is not." Consequently, in case of no implicit vars other
than `this` resolveIn is to be considered sourceless. However, mappings
are operations and implicit `this` is applicable to them. In the sample
below resolveIn has no source whereas the mapping has implicit `this` as
its source:

main(in pack : EPackage) {
resolveIn(transfMapping); -- get target objects for all executions of
`transfMapping` on any contexts
map transfMapping(pack); -- a synonym of `this.map transfMapping(pack)` }

Cheers,
Alex.

Sergey Boyko wrote:
> Hi Alex,
>
> QVT specification defines mapping operation as follow:
> "8.2.1.15 MappingOperation.
> A mapping operation is an operation implementing a mapping between one
> or more source model elements into one or more target model elements."
>
> And helpers as follow:
> "8.2.1.12 Helper
> A helper is an operation that performs a computation on one or more
> source objects and provides a result."
>
> This means that contextless mapping definition should contain at least
> one [in/inout] parameter.
> So definition
>
> mapping a() : EClass {
> name := 'a-contextless';
> }
>
> seems to be incorrect.
>
>
> There is another possibility for ambiguity. Let's change second mapping
> definition to the following:
>
> mapping a(in eCls : EClass) : EClass {
> name := 'a-contextless';
> }
>
> According to mapping call rule it's not clear what mapping is to be
> invoked for the following call:
>
> map a(myClass); -- suited for both mappings definition
>
> I think compilation warning should be produced in such case.
> And I believe that for similar situations when it's not clear what
> operation/mapping should be invoked warning about invocation ambiguity
> is rational solution.
>
>
> For the resolveIn expression I believe that invocation with context is
> preferred that contextless one. In case one explicitly needs contextless
> invocation then reference to a transformation instance should be used:
>
> this.resolveIn(EClass::a, EClass)
>
> This call is not ambiguous since it's not allowed to use transformation
> instance as mapping source.
>
>
> Regards,
> Sergey.
>
>
>> Hi All,
>>
>> Operational QVT enables to write some constructions with and without
>> context. These are mappings and resolveIn expressions. For instance,
>> one can define two mappings
>>
>> mapping EClass::a() : EClass {
>> name := 'a-context';
>> }
>>
>> mapping a() : EClass {
>> name := 'a-contextless';
>> }
>>
>> And invoke them this way:
>>
>> myClass.map a(); -- first mapping
>> map a(); -- second mapping
>>
>> The following ambiguity is not resolved in the spec. How should the
>> QVT engine behave in case of implicit variables in the environment.
>>
>> Sample:
>>
>> var d := Sequence { object EClass { name := 'a'},
>> object EClass { name := 'b'}};
>> var e := d->collect(map a());
>>
>> In this case there is an implicit iterator of the 'collect'
>> expression. That's why 'mapping EClass::a() : EClass' is to be called.
>> On the other hand, there is a contextless version of mapping a().
>> Therefore, 'mapping a() : EClass' is to be called. The question is
>> which mapping is more preferrable? Or make it a compiler error/warning
>> requiring the user to change mapping names?
>>
>> When it comes to resolveIn expressions the situation is even worse,
>> since 'this' in transformations is always implicit:
>>
>> var d := Sequence { object EClass { name := 'a'},
>> object EClass { name := 'b'}};
>> var f := d->collect(resolveIn(EClass::a, EClass));
>>
>> What should be used here: sourceless resolveIn or resolveIn on
>> 'collect' iterator? Apart from collect exps, in case of simple
>> 'resolveIn(EClass::a, EClass)' should sourceless resolveIn be used or
>> should it be resolveIn on 'this'?
>>
>> Your thoughts, please?
>>
>> Best,
>> Alex.
Previous Topic:Problem with transformation DSM2UML
Next Topic:[ATL] Group elements together in target model
Goto Forum:
  


Current Time: Sun Apr 11 22:49:04 GMT 2021

Powered by FUDForum. Page generated in 0.03546 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top