Re: _event.data type in tests

Le 7 apr 2013 à 18:59, Stefan Radomski a écrit :

> I am still trying to pass the revised tests and stumbled upon a distinction of _event.data in case of error between test343 and test488:
> 
> test343: <transition event="done.state.s0" cond="_event.data == null" target="pass"/>
> test488: <transition event="done.state.s0" cond="_event.data === ''" target="pass"/>
> 
> In test343, we try to assign from an undeclared variable via donedata/param and in test488 we try to do the same with a ECMAScript keyword ("return"). I don't think this distinction makes sense as both cases test for "empty data". We agreed upon "undefined" for strings in _event - what to make of data now?


The spec (5.7) says that if the 'expr' attribute of <param> produces an error, the interpreter must ignore the whole <param>. So if no <param> works, we should behave as if there had been an empty <donedata>. Which is not quite well defined:

We decided that an empty <content> would produce _event.data=undefined, but <content> is supposed to set the value of the entire _event.data whereas <param>s only affect one property of it. The "limit" of _event.data when the number of <param>s reaches zero is {} (an object with zero properties). {} makes a lot of sense to me. The only reason to choose undefined over {} is that {} is not falsy. But if you expect an event to come from something with <param>s then it doesn't make sense to test if _event.data===undefined. You're going to be interested in properties of _event.data. The object itself is just a container.

So the test could be more open-minded like this:
cond="! _event.data || ! ('foo' in _event.data)"

thus ensuring that the <param> was totally ignored, as specified, but going no further.

If at some point we need an ECMAScript test to check the exact value returned in that case, we can make one.

			David

Received on Sunday, 7 April 2013 18:48:07 UTC