Mailingliste - Einträge 2006


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

Re: [qftestJUI] problem with setting variables


  • Subject: Re: [qftestJUI] problem with setting variables
  • From: Gregor Schmid <Gregor.Schmid@?.de>
  • Date: 29 Oct 2006 20:45:54 +0100

Hello Eyere,

Mark is right about the lazy variable problem, though I wouldn't
really call it a bug. Lazy variable expansion has its advantages. The
problem is that it is the default and only option and we will indeed
change that (sooner or later, I hope sooner :-).

What I'd like to know is whether Mark's answer solves your problem. If
not, I'll need a run-log with the details to see what's going on in
your case.

Best regards,
    Greg

"Michaelis, Mark" <mark.michaelis@?.com> writes:

>    Hello,
> 
> 
> 
>    I suggest you stumbled upon the same problem I did before. I
>    personally call it lazy variable expansion-bug. As far as I know there
>    is a fix introduced in 2.0.
> 
> 
> 
>    If you have something like (meta-notation for actual qftestJUI nodes):
> 
> 
> 
>    function fun1():
>      local myVar = "fun1"
>      print fun2(myVar)
> 
> 
> 
>    function fun2(myArg):
>      local myVar = "fun2" # mind: we don't use myVar here; it _should_ be
>    a total dummy statement
>      return myArg
> 
> 
> 
>    This will output "fun2" although at least I would expect "fun1" as
>    output. As you might have observed fun2 should do nothing else than
>    returning the argument. While the myVar-setting is not used at all and
>    in other programming languages the statement would have been just
>    ignored. The problem is that until "myArg" is used it still just holds
>    a named reference to the variable. So when myArg is finally accessed
>    in the return statement of fun 2 qftestJUI looks for a variable with
>    the name "myVar" and will find "fun2" in that context.
> 
>    The workaround is quite easy though ridiculous:
> 
>    function fun1():
>      local myVar = "fun1"
>      print fun2(myVar)
> 
>    function fun2(myArg):
>      local myArg = myArg # !!!!!
>      local myVar = "fun2"
>      return myArg
> 
>    I. e. explicitly access the arguments (assigning them to themselves)
>    before doing anything else. I personally like to place it into a
>    sequence named "Workaround Lazy Variable Expansion Bug". This
>    hopefully helps me removing all this irritating sequences when getting
>    to qftestJUI 2.0.
> 
>    Only thing which makes me puzzled: I did not have this problem with
>    global variables yet. But perhaps it's the very same issue. Some more
>    details would be interesting: Do you set the value "dsdsds" anywhere?
> 
>    Regards,
> 
>    - Mark
> 
>    --
>    Mark Michaelis
>    Software Engineer Quality Assurance
>    CoreMedia AG
>    Ludwig-Erhard-Str. 18
>    20459 Hamburg, Germany
>    www.coremedia.com
>    -------------------------------------------------------
>    Any Content, Anywhere, in a Trusted Universe:
>    CoreMedia CMS and CoreMedia DRM
> 
> _______________________________________________
> qftestJUI-list mailing list
> qftestJUI-list@?.de
> http://www.qfs.de/mailman/listinfo/qftestjui-list

-- 
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