Re: Understanding manual SCXML test 307.

I see, thanks. The following (post-transform) test would pass in LXSC, but I am guessing that it would fail in others' ECMAScript models. JSSCXML, uSCXML, am I right? If testvar1 is set to {} in your data models, does accessing testvar1.nonono raise an error?

<scxml xmlns="http://www.w3.org/2005/07/scxml" version="1.0" initial="s0" binding="late">
  <state id="s0">
    <onentry>
      <log label="testvar1 is: " expr="testvar1"/>
      <raise event="foo"/>
    </onentry>
    <transition event="error" target="s1"><log label="error in s0" expr="_event"/></transition>
    <transition event="foo" target="s1"><log label="no error in s0" /></transition>
  </state>
  <state id="s1">
    <datamodel><data id="testvar1" expr="{}"/></datamodel>
    <onentry>
      <log label="testvar1.nonono is: " expr="testvar1.nonono"/>
      <raise event="bar"/>
    </onentry>
    <transition event="error" target="final"><log label="error in state s1" expr="_event"/></transition>
    <transition event="bar" target="final"><log label="No error in s1" expr=""/></transition>
  </state>
  <final id="final"/>
</scxml>


--
(-, /\ \/ / /\/

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

The relevant language is in section 5.9:

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. Such behavior is defined by the data expression language in use.


The idea is that in late binding, the variables are created at startup time, but no values are assigned.  It's is possible that test307 is too ECMA specific and needs to be modified.  

- Jim

On 6/30/2014 6:12 PM, Gavin Kistner wrote:
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
 
 

-- 
Jim Barnett
Genesys