- From: David Junger <tffy@free.fr>
- Date: Tue, 18 Mar 2014 16:42:30 +0100
- 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. David
Received on Tuesday, 18 March 2014 15:43:01 UTC