Re: Understanding manual SCXML test 307.

Alright, then I'm failing this test. This seems like an odd assertion, however. Can you point me to the spec section covering it?

For why it's odd: for my data model, the 'global' scope in which data model values are assigned and code is evaluated is a Lua table (think ECMAScript object, or hash). I can ask for a missing value and get back a value of nil.

If this test were to set the data model location to a new empty table/object/hash, then the behavior when I access a missing property on it would be identical. But this test does not set the data model to a value that can have child properties. It sets it to a scalar value. In ECMAScript 'everything is an object' and so has empty properties. In Lua, this is not so:

t = {}
print(t.foo) --> nil
n = 123
print(n.foo) --> ERROR: attempt to index global 'n' (a number value)

I sort of pass this test in spirit. I'm beginning to wonder if I shouldn't just change the whole LXSC data model to require predeclaration of variables, just to match the expectations of the de-facto data model which informed the writing of the tests. :/
--
(-, /\ \/ / /\/

On Jun 30, 2014, at 03:56 PM, Jim Barnett <1jhbarnett@gmail.com> wrote:

The relevant assertion is:

When "late" data binding is used, accessing data substructure in 
expressions before the corresponding data element is loaded MUST yield 
the same execution-time behavior as accessing non-existent data 
substructure in a loaded data instance.

So to pass the test, you should have the same output in s0 and s1, 
meaning either no error in both, or an error in both.

- Jim
On 6/30/2014 4:17 PM, Gavin Kistner wrote:
        > I cannot tell from the leading comment how to determine if this test 
        > is passing or not. I currently get these messages:
        >
        > entering s0 value of Var 1 is: : nil
        > no error in s0
        > error in state s1: <event      >{type="platform", 
        > name="error.execution.evaluation", data="[string \"return 
        > testvar1.nonono\"]:1: attempt to index global 'testvar1' (a number 
        > value)"}
        >
        > This looks correct to me, but I wanted to be sure. It looks to me like 
        > this test may have been expecting an error in the first log, under the 
        > assumption that all data models would raise an error reading a value 
        > that had not yet been set.
        >

-- 
Jim Barnett
Genesys