Confirmed users
446
edits
JavaScript:SpiderMonkey:LongTermPlans: Difference between revisions
JavaScript:SpiderMonkey:LongTermPlans (view source)
Revision as of 20:14, 6 February 2014
, 6 February 2014Note removal of shortids/tinyids
(Link to some existing bugs) |
(Note removal of shortids/tinyids) |
||
| Line 65: | Line 65: | ||
C string APIs were historically pretty convenient. These days, though, with the recent addition of <code>MOZ_UTF16</code>, it's easy to write UTF-16 strings in source code. APIs that take C strings now, should be converted to take 16-bit-wide strings and lengths. This potentially eliminates an inflate operation and reduces the number of different string types to think about. It also makes non-ASCII strings be handled by the default case, which is good for correctness. | C string APIs were historically pretty convenient. These days, though, with the recent addition of <code>MOZ_UTF16</code>, it's easy to write UTF-16 strings in source code. APIs that take C strings now, should be converted to take 16-bit-wide strings and lengths. This potentially eliminates an inflate operation and reduces the number of different string types to think about. It also makes non-ASCII strings be handled by the default case, which is good for correctness. | ||
=== Remove shortids and tinyids === | |||
In ECMAScript, properties are referred to by strings, full stop. ES6 and our implementation add some flourishes to this (symbols/property keys, access by <code>uint32_t</code>), but it remains the case that properties have only one name, and that name corresponds to the concept defined by ECMAScript, or a pure transformation of it. | |||
Allowing properties to exist using a different name than the canonical ECMAScript name introduces a fair bit of complexity into SpiderMonkey. (And if there's a part of SpiderMonkey that absolutely can't afford extra complexity, it's our property representation/lookup code paths.) Doing so doesn't appear to have a memory cost, because the extra name fits into what would otherwise be padding. But it's extra work to keep track of it, extra work to preserve it, extra work to distinguish properties that differ only in their shortid -- and all this only for the benefit of users of <code>JSPropertyOp</code> and <code>JSStrictPropertyOp</code>, which as previously noted we want to remove. | |||
=== Removal of the <code>jsval</code> typedef in favor of <code>JS::Value</code> === | === Removal of the <code>jsval</code> typedef in favor of <code>JS::Value</code> === | ||