New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add toNumber
and cleanup toString
. Plus a wide range of tests.
#1577
Conversation
Preserve sign of `0`.
lodash#1574 Cleanup `toString` and added a wide range of tests. lodash#1576 (comment)
Ok, something funky with node v0.8, but don't have the time to investigate just now, must sleep and have to take kids to museum tomorrow. Maybe the hex bug that I mentioned in my enhancement post. I'm also unsure if QUnit's deepEqual test for -0 |
Add more `toNumber` tests.
# Conflicts: # lodash.js # test/test.js
That should cover most of the basic use cases, and catch any basic bugs/deficiencies. There are plenty more that could be added to catch other bugs, like I mentioned with Opera where an object has valueOf defined but it's not a function. Other (highly)possible environment deficiencies are regarding whitespace, where the native trim does not trim correctly. Which some could be corrected by if value is string then return +trimmed rather than fall through to return +value. This still leaves return +value coercion open to environment deficiencies. |
…vent some whitespace deficiencies.
To catch even more string issues, the type value === 'string' could be extended to String objects by using isString(value) instead. |
Finally (for now), do we keep this early return for number types?
|
Add tests for Boolean objects. Add test for RegExp object.
So, node v0.8 has a problem with this case again converting bad hex strings. |
…urrent they fall through to return +value. Should find deficiencies in environments.
Now need to find a simple fix without implementing a full toPrimitive shim, if possible. |
if (reIsOctal.test(trimmed)) { | ||
return parseInt(trimmed.slice(2), 8); | ||
} | ||
if (reIsBadHex.test(trimmed)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't bad hex fall out naturally as NaN
from the +trimmed
below?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will look at improving the flow.
Clamp to range 0 to 2^32-1 (MAX_ARRAY_LENGTH), to match other methods.
Improve `reIsUint` to filter strings like `0001 and add tests.
Add `toLength` and basic tests.
Can you rebase this PR. |
# Conflicts: # lodash.js # test/test.js
f35a15b
to
39a22bf
Compare
I've created a (more) optimised version (I think a little more could be done), instead of calling lodash methods. I don't know if you'd prefer this instead, as it looks like I need to rebase again?
|
Not a fan of that. Less is more. |
} | ||
return +value; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be simplified:
function toNumber(value) {
var result = +value;
if (typeof value == 'number' || result === result) {
return result;
}
value = trim(value);
var isBinary = reIsBinary.test(value);
return (isBinary || reIsOctal.test(value))
? nativeParseInt(value.slice(2), isBinary ? 2 : 8)
: result;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is going to fail on at least node v0.8 I believe. But that should just be a case of adding the bad hex test back in. It's nice to see where your experience pays off wrt simplification. Let me change it and we can see.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah cool, verified 0.8 does not return NaN
:P
Ok, I'll just rebase it. |
I don't know if it is just me, but git doesn't seem very good at auto merging simple upstream changes? I seem to need to do a fair amount of manual merging each time. And it always worries me that I may get it wrong. :) |
It'll be easier in your branch to copy the lodash.js and test.js to another location then. git reset --hard c142cfc81dce4c3cbd3ff4ceb33e13df13062be9
# add your lodash.js and test.js back
git add -u
git commit -m "Add _.isNumber."
git push origin +master |
# Conflicts: # lodash.js # test/test.js
I guess I'll get better at it, at the end of the day I'm just a self taught enthusiast. ;) Node v0.8 and v0.10 don't seem happy with that new code. |
Closed via 3795534. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
#1574
#1576 (comment)