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

Re: [SCXML] bad tests with inline values

From: Zjnue Brzavi <zjnue.brzavi@googlemail.com>
Date: Tue, 18 Mar 2014 20:02:55 +0000
Message-ID: <CABmmmmxx+wMHKEmmt3LCSSrOC90d0q2i58bRBUj4q6qZU4MsmA@mail.gmail.com>
To: David Junger <tffy@free.fr>
Cc: Voice Public List <www-voice@w3.org>
> > 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
Received on Tuesday, 18 March 2014 20:03:23 UTC

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