Re: [SCXML] bad tests with inline values

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

Hi,

I'd prefer it to work intuitively all of the time :)
We're discussing the ecma model afterall and all valid ecmascript should be
accepted, so fine by me either way.

Zjnue