Bug 15959
| Summary: | JSObject needs getToNumber to avoid costly string/number conversions | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | barraclough, darin, ggaren, max.hong.shen, mjs |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
Eric Seidel (no email)
JSObject needs getAsNumber to avoid costly string/number conversions
This would be very useful for the bracket access operator on String when used in a numeric context, no create a substring to hold a single UChar.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Eric Seidel (no email)
Funny, we were discussing this on Friday... re-editing what you wrote and having it come out in sentence fragments. I meant "a numeric context. There would then be no need to create a substring...".
Geoffrey Garen
How does this fit in with "toNumber" and "getNumber"?
What does getAsNumber return if the value is not a number?
Eric Seidel (no email)
Hum... what I should have said was "getToNumber", since the idea behind all of the "evaluateToFoo" calls is that they're equivalent to to calling evaluate(exec)->toFoo(exec). I would want the same to hold true for any get variants. so this should be the awkward name, "getToNumber". I feel like I'm herding values or something...
Gavin Barraclough
We do now have separate paths for string/numeric property access; I don't think this bug is still tracking a viable change.