Re: [SCXML] bad tests with inline values

Le 18 mar 2014 à 15:20, Zjnue Brzavi <[email protected]> a écrit :

> Perhaps also mentioning the test cases where the current definition is creating difficulty:
> 
> test179.scxml:
>  * data definition : <content>123</content>
>  * equality test : <transition cond="_event.data == '123'" ... ( should be <transition cond="_event.data == 123")
> 
> test529.scxml:
>  * data definition : <content>21</content>
>  * equality test :<transition cond="_event.data == '21'" ... ( should be <transition cond="_event.data == 21" )
> 
> If the change is made, we could probably return to strict equality ( === ) tests instead of ==.

But why would we *want* to use strict equality? As those tests demonstrate, == works intuitively (most of the time) to provide the expected result despite type mismatch. Moreover, as I pointed out before, == allows the possibility of interpreting the data as space-normalized text instead of JSON, and all it costs us is… well, nothing, it's even shorter :)

I'd rather keep using equivalence (==) and forget about types unless the type actually matters for a particular test or is semantically relevant. Actually, I wouldn't mind if the tests using X === undefined (or even typeof X === 'undefined') used !X instead. When is it useful to know that _event.data was explicitly set to an empty string as opposed to not set at all? Even worse, how about when _event.data is set explicitly to undefined? that would be undetectable under the current event representation, no matter how many equal signs you use.

			David