[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qftestJUI] Question concerning QF-Test procedures and variable bindings.
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