Mailingliste - Einträge 2006


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qftestJUI] Question concerning QF-Test procedures and variable bindings.


  • Subject: Re: [qftestJUI] Question concerning QF-Test procedures and variable bindings.
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: 31 Oct 2006 13:52:36 +0100

Hi Adrian, Mark,

the behavior Adrian described is indeed a side-effect of the "Lazy
Variable Expansion" problem. If you read through the variables chapter
in the manual and picture the primary and fallback bindings stacks
resulting from your example, you'll see that both default parameter
bindings end up on the fallback stack. Better yet, use QF-Test version
2 Beta, step into the example and take a look at the variable bindings
in the debugger window.

If the caller of proc1 specifies a value, this binding is on the
primary stack, overriding both defaults and things work as expected.

Without a direct binding, the defaults of proc2 on the fallback stack
have higher precedence than the defaults of proc1. Again, this is the
right thing.

The problem is that in the call from proc1 to proc2 you tried to
create an explicit binding for the timeout value and this is one place
where lazy expansion falls short. The value thus bound on the primary
variable stack is "$(timeout)", leading to recursive expansion and
lookup in the fallback stack just as if the binding never happened.

Now while we're discussing things at this level of detail, here's my
proposed fix:

- we introduce one or two additional syntax variants for variable
  expansion (alternative symbol suggestions welcome, but I think the
  following are quite intuitive):

  $!(xxx) for immediate expansion

  $_(xxx) for lazy expansion

The question remains what to do about the default $(xxx). Backward
compatibility would require to keep this as lazy. However, I expect
that very few people are actively taking advantage of lazy expansion
for "future" bindings, and if so only in a few, isolated places while
many have been bitten by the surprising result of lazy expansion. So I
think we should make immediate expansion the default.

Best regards,
    Greg

"Adrian Chamberlain" <Adrian.Chamberlain@?.com> writes:

> Hi Mark,
> 
> Thank you for the feedback with reference to my question concerning
> procedures and variable bindings.
> 
> I feel the example I gave was not a good one, and I failed to put my
> question across clearly.  Although your comments, regarding the script, and
> the use of rc.lookup, were indeed applicable to the poor example I provided
> in the attached test-suite file.
> 
> 
> Here is another attempt to try and clarify my question :-
> 
> The following example has two procedures:
> 
> Procedure 'proc1' which takes a parameter named 'timeout'
> Procedure 'proc2' which also takes a parameter named 'timeout'
> 
> Procedure 'proc1' specifies a default value of '200' for the parameter
> 'timeout'
> Procedure 'proc2' specifies a default value of '300' for the parameter
> 'timeout'
> 
> i.e.
> 
> Procedure proc1( 'timeout' : default='200' )
>     call procedure proc2( $(timeout) )
> End Procedure
> 
> Procedure proc2( 'timeout': default='300' )
>     <server script - rc.lookup("timeout")>
>      REM: doing an rc.lookup will result in an entry in the run log showing
> the value for the local variable binding 'timeout'.
> End Procedure
> 
> Example test-suite file:
> (See attached file: example.qft)
> 
> If procedure 'proc1' is called, and the caller provides the parameter
> 'timeout' (rather than an empty parameter list) i.e.
>     call procedure proc1('timeout' : '100')
> then examination of the run log shows that the variable binding 'timeout'
> has the value '100', with reference to the rc.lookup in procedure 'proc2'.
> This is of course correct.
> 
> (See attached file: 100.qrz)
> 
> If on the other hand, the caller does not provide the 'timeout' parameter
> in their 'call procedure' node i.e. an empty parameter list.,
>     call Procedure proc1()
> then examination of the run log shows that the variable binding 'timeout'
> has the value '300', with reference to the rc.lookup in procedure 'proc2'.
> 
> (See attached file: 300.qrz)
> 
> I would have expected the value for 'timeout' to have been '200' (i.e.
> rc.lookup("timeout")), as this is the default value assigned to the local
> variable 'timeout' within the procedure 'proc1', and subsequently passed to
> procedure 'proc2'.
> 
> Apologies if I am missing something simple here.   Its probably something
> silly which is staring me in the face (may be its time for a holiday!).
> 
> I thought the whole idea of being able to set a default value for the
> parameter to a procedure (like in C++), was to ensure that upon execution
> of that procedure,  you could be certain that there was an initialised
> local variable binding (i.e. 'timeout' equal to '200; on the procedures
> stack frame), if the caller to that procedure (i.e. 'proc1') fails to
> provide anything but an empty parameter list in their 'call procedure'
> node.
> 
> Any comments on the above from other would be welcomed.
> 
> Thank you
> Regards
> Adrian

-- 
Gregor Schmid                                Gregor.Schmid@?.de
Quality First Software GmbH                     http://www.qfs.de
Tulpenstr. 41                                Tel: +49 8171 919870
DE-82538 Geretsried                          Fax: +49 8171 919876


Videos Downloads Dokumentation Kaufen Gratis Testen