W3C home > Mailing lists > Public > www-voice@w3.org > January to March 2014

Re: [SCXML] bad tests with inline values

From: Jim Barnett <1jhbarnett@gmail.com>
Date: Wed, 19 Mar 2014 10:06:42 -0400
Message-ID: <5329A472.5020407@gmail.com>
To: www-voice@w3.org
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:44 UTC