- From: James Graham <jgraham@opera.com>
- Date: Sun, 10 Apr 2011 19:15:01 +0200 (CEST)
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, public-test-infra <public-test-infra@w3.org>
On Sat, 9 Apr 2011, Garrett Smith wrote: > On 4/7/11, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote: >> On Wed, Apr 6, 2011 at 10:28 PM, Garrett Smith <dhtmlkitchen@gmail.com> >> wrote: >>> I don't have time for this. Ask on comp.lang.javascript. >> >> Nor do I have time to research the reasoning that underlies your\ > Uh oh. So the explanations weren't enough, got it, so I tried to head > you off in the right direction. > > https://groups.google.com/group/comp.lang.javascript/browse_thread/thread/3550757564c1f24a?hl=tk# > I've outlined some of the fundamental problems I saw in the code. I > already made the NUnit suggestion on this list (or was it the public > webapps?) Thanks for soliciting wider review. Do you plan to summarise feedback from that list here? I think it is quite likely that I will unintentionally forget to check back and see if there are any useful suggestions. On the subject of assert_NaN; I am quite happy to add that for the since being explicit is generally good. However assert_equals always failing when passed NaN would be a likely source of bugs. The two reasonable choices seem to be "throw" or "just work". I am not sure what is wrong with "just work". In particular I think it is quite obvious to anyone reading what assert_equals(NaN, something) does. Yes, it depends on a notion of equality that is a little different from the two notions of equality exposed by the ECMAScript == and === operators. On the other hand, the ES5 internal SameValue algorithm treats NaNs as equal so it is clearly not a totally alien concept.
Received on Sunday, 10 April 2011 17:15:34 UTC