Repository navigation
assert.js rule 7.4 (similar to CJS rule 7.3) #9063
Description
- Version:
v6.1.0 - Platform:
Linux ███ 3.13.0-97-generic #144-Ubuntu SMP Thu Sep 22 16:23:22 UTC 2016 i686 i686 i686 GNU/Linux - Subsystem: assert
Hi,
I'm developing an assert lib and it disagrees with node's. While debugging, I found rule 7.4 in master/lib/assert.js @ d4061a6 that to me sounds very similar to rule 7.3 in the CJS spec:
// 7.4. Other pairs that do not both pass typeof value == 'object',
// equivalence is determined by ==.
} else if ((actual === null || typeof actual !== 'object') &&
(expected === null || typeof expected !== 'object')) {I think the condition tests both values for being primitives, aka not objects. Firefox seems to agree:
var actual = true, expected = [ 1 ];
console.log([ (actual === null || typeof actual !== 'object'), '&&',
(expected === null || typeof expected !== 'object') ]);
// -> Array [ true, "&&", false ]So one passes the object check, the other does not, as expected.
Is it a pair where both values pass the object check? No.
So shouldn't it count as a "[pair] that do not both pass typeof […] object"?
If the partial conditions negate the object check and check for being primiteves instead, shouldn't the binary operator change to ||?
Pre-emptive: In case anyone feels inclined to discuss the quality of the CJS UT spec and/or how much better deepStrictEqual is, please make another issue for that.
Activity
cjihrig commentedon Oct 12, 2016
Just to clarify, can you provide a call to the
assertmethod that is working incorrectly?mk-pmb commentedon Oct 12, 2016
Nope, that would be the next step. I first have to understand exactly which behavior is intended as correct; only then I can know whether it is working incorrectly at all.
The code example in the other thread is not applicable because that one is about the CJS UT spec, the one at the URL stated in line 1 of node's
assert.js.However, that's obviously not the spec being used here, as it has no mention of RegExps at all, whereas node's
assert.jshas rule 7.3 specifically for RegExps.(I don't care why the URL is in line 1 – if anyone does, please make another issue for that. ;-) )
We can care about specs later, but for now my goal in this issue is just to solve the cited dissonance between comment and code.
Trott commentedon Oct 12, 2016
If it helps explain anything: The
7.4and some of the other numbers in the comments are just wrong. They were changed in a805012d and almost certainly in other commits as well. Apparently people did not realize that the numbers (of the form7.3) were not arbitrarily invented by Node.js but were part of an external standard, so they just modified them when it seemed to make sense to them. Thus, they are out of sync with the standard.Side note: A good first commit for a new contributor might be to remove all those numbers so that no one thinks they are supposed to map to the standard. We've likely deviated from it and even if we haven't, we likely happily would if it suited our needs.
mk-pmb commentedon Oct 12, 2016
Removing the old numbers, and adding an annotation to the spec URL (or removing it) will probably avoid some bug reports in case the code is kept and the comment is edited to match it.
I suggest to add new numbers though (maybe prefixed with "N"?) to simplify discussion about them independent of line numbers.
Fishrock123 commentedon Oct 12, 2016
We don't follow CJS so the comments should not be considered part or forming any standard but rather just regular code comments. They may change at any time.
mk-pmb commentedon Oct 13, 2016
How about replacing the comment that was 7.4 with:
I think that's what the current code does.
Trott commentedon Oct 13, 2016
A contribution that makes the comments more accurately and clearly reflect what is going on in the code would be welcome.
assert: update comments
assert: update comments
assert: update comments
assert: update comments
assert: update comments
assert: update comments
assert: update comments
assert: update comments
assert: update comments