52
edits
JavaScript:SpiderMonkey:LongTermPlans: Difference between revisions
JavaScript:SpiderMonkey:LongTermPlans (view source)
Revision as of 20:50, 27 April 2021
, 27 April 2021Mark as Outdated
(Mark as Outdated) |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{outdated}} | |||
The technical plans described below are long-term goals for SpiderMonkey. We aren't necessarily actively working toward completion of any of them. We do try to fix bugs in the short term, in ways that will make these plans easier, or will not get in their way. | The technical plans described below are long-term goals for SpiderMonkey. We aren't necessarily actively working toward completion of any of them. We do try to fix bugs in the short term, in ways that will make these plans easier, or will not get in their way. | ||
| Line 58: | Line 60: | ||
Most of the JSAPI is old, C-style <code>JS_*</code> functions. These functions' APIs often aren't particularly simple, clean ways to implement those behaviors. A pleasant C++ API that reads more simply, and doesn't necessarily expose operations through hundreds of freestanding methods, would be nice. We've incrementally introduced such APIs at lower levels -- see for example <code>JS::Value</code> -- but we haven't done anything yet at higher levels. Mostly this is a matter of inertia, and of API design being a bunch of hard work that's off the critical path for Firefox. We'd probably welcome help from embedders and the like with special interest and expertise in designing nice, clean C++ APIs for this stuff. (Do note, however, that we still require an exception-safe API -- true/false return values to indicate success will still probably be necessary.) | Most of the JSAPI is old, C-style <code>JS_*</code> functions. These functions' APIs often aren't particularly simple, clean ways to implement those behaviors. A pleasant C++ API that reads more simply, and doesn't necessarily expose operations through hundreds of freestanding methods, would be nice. We've incrementally introduced such APIs at lower levels -- see for example <code>JS::Value</code> -- but we haven't done anything yet at higher levels. Mostly this is a matter of inertia, and of API design being a bunch of hard work that's off the critical path for Firefox. We'd probably welcome help from embedders and the like with special interest and expertise in designing nice, clean C++ APIs for this stuff. (Do note, however, that we still require an exception-safe API -- true/false return values to indicate success will still probably be necessary.) | ||
=== Replace <code>jschar</code> with <code>char16_t</code> === | === <strike>Replace <code>jschar</code> with <code>char16_t</code></strike> (FIXED) === | ||
Recent changes mean that SpiderMonkey's historical <code>jschar</code> type is identical to <code>char16_t</code> (an emulated <code>typedef</code> in older compilers). We should cut out the middle man and just use <code>char16_t</code> directly. This is mostly a large search-and-replace operation on Gecko and JSAPI headers. | Recent changes mean that SpiderMonkey's historical <code>jschar</code> type is identical to <code>char16_t</code> (an emulated <code>typedef</code> in older compilers). We should cut out the middle man and just use <code>char16_t</code> directly. This is mostly a large search-and-replace operation on Gecko and JSAPI headers. | ||
* Fixed by {{bug|1063962}} | |||
=== Replace <code>const char*</code> with <code>const char16_t*</code> === | === Replace <code>const char*</code> with <code>const char16_t*</code> === | ||
| Line 66: | Line 70: | ||
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 === | === <strike>Remove shortids and tinyids</strike> (FIXED) === | ||
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. | 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. | 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. | ||
* {{bug|797126}} - Remove tinyid/shortid | |||
=== <strike>Removal of the <code>jsval</code> typedef in favor of <code>JS::Value</code></strike> (FIXED) === | === <strike>Removal of the <code>jsval</code> typedef in favor of <code>JS::Value</code></strike> (FIXED) === | ||