|
Re: [QVTOM] Deferred resolves [message #73592 is a reply to message #73572] |
Mon, 28 January 2008 15:04 |
Radomil Dvorak Messages: 249 Registered: July 2009 |
Senior Member |
|
|
Hi Alfons,
In principal, you could use late resolve inside any ocl expression as it's
just an expression
of a given type, but this would not make much sense. It just results in
null during normal execution
time and if not used in assignment, there is no place to store the result
of deferred evaluation.
The current implementation supports deferred assignment only with
properties,
as the execution semantics is clear in this case.
Though, if assigning to variables, perhaps, one could assign intermediate
results there and use it in
subsequent deferred assignments, in case that these assignments have that
variable in its scope.
However, the QVT spec is not very clear about this and the QVTO compiler
reports a 'warn' now, saying
you should use late resolve with property assignment to get it assigned at
deferred time.
Regards,
Radek
On Mon, 28 Jan 2008 13:20:48 +0100, Alfons Laarman
<a.w.laarman@student.utwente.nl> wrote:
> Hi all,
>
> The QVT specification defines an interesting concept called deferred
> resolve
> or late resolve.
> Resolution is done after the transformation is completely executed and
> the
> result is stored.
> My question is about this storage of the result, the spec says the
> following
> about the execution semantics: A null value is returned instead. In the
> meantime, the execution engine stores the following information for the
> future variable: the source object, the function representing the
> filtering
> expression and the property or the variable reference to be assigned.
> This
> information is sufficient to allow the assignment to be performed later -
> more precisely ñ at the end of the execution of the entry operation of
> the
> transformation.
>
> What use it to store the result to a variable after the transformation
> execution. Can somebody explain this to me?
> Also can a deferred resolve occur inside an ocl expression? From the
> above
> information i can somehow deduce that it should not, otherwise we didnt
> store enough information to execute the ocl expression after the
> execution.
> But this is not explicitely stated.
>
>
> Best regards,
>
> Alfons
>
>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
Re: [QVTOM] Deferred resolves [message #73666 is a reply to message #73592] |
Mon, 28 January 2008 19:10 |
Alfons Laarman Messages: 71 Registered: July 2009 |
Member |
|
|
"Radek Dvorak" <radek.dvorak@borland.com> schreef in bericht
news:op.t5naubwehj1a1g@czprl-rdvorak2.emea.borl.net...
> The current implementation supports deferred assignment only with
> properties,
> as the execution semantics is clear in this case.
> Though, if assigning to variables, perhaps, one could assign intermediate
> results there and use it in
> subsequent deferred assignments, in case that these assignments have that
> variable in its scope.
> However, the QVT spec is not very clear about this and the QVTO compiler
> reports a 'warn' now, saying
> you should use late resolve with property assignment to get it assigned at
> deferred time.
>
Thanks for your answer, Radek.
It just would not make sense to implement it with variables. It will make
QVTOM partly declarative, and the specs claim it is completely
imperative....
Alfons
|
|
|
Powered by
FUDForum. Page generated in 0.03320 seconds