Re: [SCXML] bad tests with inline values

Jim Barnett <[email protected]>
Newsgroups gmane.comp.web.voice
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.