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

Re: [SCXML] bad tests with inline values

From: David Junger <tffy@free.fr>
Date: Tue, 18 Mar 2014 16:42:30 +0100
Message-Id: <A2D3F183-8F88-47B1-9BC0-DD779FEBDBD0@free.fr>
To: Voice Public List <www-voice@w3.org>
Le 18 mar 2014 à 15:20, Zjnue Brzavi <zjnue.brzavi@googlemail.com> a écrit :

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

Received on Tuesday, 18 March 2014 15:43:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:04:01 UTC