Confirmed users
446
edits
JavaScript:SpiderMonkey:LongTermPlans: Difference between revisions
Jump to navigation
Jump to search
JavaScript:SpiderMonkey:LongTermPlans (view source)
Revision as of 01:42, 4 February 2014
, 4 February 2014jschar/char16_t situation cleanup
(CodeGenerator arch-specific/agnostic separation) |
(jschar/char16_t situation cleanup) |
||
| Line 26: | Line 26: | ||
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> === | |||
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. (Although as a short-term compatibility hack, we may still want to preserve a <code>jschar</code> typedef for the short run, maybe in SpiderMonkey 31, with full removal in 38.) | |||
=== Replace <code>const char*</code> with <code>const char16_t*</code> === | |||
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. | |||
=== 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> === | ||