Re: [SCXML] bad tests with inline values

I'm not sure that I understand the conclusion of this discussion. Do we 
have agreement on what to do with the tests?


On 3/18/2014 4:02 PM, Zjnue Brzavi wrote:
>
>     > 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

-- 
Jim Barnett
Genesys

Received on Wednesday, 19 March 2014 14:07:27 UTC