Re: _event.data type in tests

On 07.04.2013, at 20:49, "David Junger" <tffy@free.fr> wrote:

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

As an implementor, I'd very much like to avoid different types for _event.data depending on whether it was an illegal param or an illegal content in the original assignment. And I'd vote to keep it as ECMAScript undefined if we cannot assign anything to _event.data. Arguing that the intention was to assign a (failed) KVP, and it should therefor be the empty object {} makes some sense but complicates matters considerably imho. 

Regards
Stefan

> 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 Monday, 8 April 2013 08:56:26 UTC