9
edits
Fixed-width strings: Difference between revisions
→SpiderMonkey compatibility
| Line 65: | Line 65: | ||
* Do we need to support external strings and their finalizers? External strings are strings created with a finalizer index, which is a 32-bit integer. Finalizers for this type are registered and deregistered. The additional index could fit into the maximum of 16 bytes for string instance data (assuming 4-byte pointers), but since the index is returned by JS_AddExternalStringFinalizer(), the implementation could be limited to, say, 8 bits, giving a maximum of 255 indexes (one index needs to be reserved for the default, built-in finalizer). | * Do we need to support external strings and their finalizers? External strings are strings created with a finalizer index, which is a 32-bit integer. Finalizers for this type are registered and deregistered. The additional index could fit into the maximum of 16 bytes for string instance data (assuming 4-byte pointers), but since the index is returned by JS_AddExternalStringFinalizer(), the implementation could be limited to, say, 8 bits, giving a maximum of 255 indexes (one index needs to be reserved for the default, built-in finalizer). | ||
* How would JS_GetStringChars() and JS_GetStringBytes() work? Would they force a narrowing of the string? In that case, the corresponding method is needed (which would not be difficult to add). | * How would JS_GetStringChars() and JS_GetStringBytes() work? Would they force a narrowing of the string? In that case, the corresponding method is needed (which would not be difficult to add). ''SRJ: What assumptions do these calls make about encoding and character width? Is it possible to deprecate them? IMHO code that can't deal with wide characters probably needs overhauling at this point anyway.'' | ||
* What about growable strings? They are contradictory to the immutability of Tamarin strings. They could be implemented, but there should be some safety measure so they cannot be passed in to the engine. | * What about growable strings? They are contradictory to the immutability of Tamarin strings. They could be implemented, but there should be some safety measure so they cannot be passed in to the engine. ''SRJ: I don't know if growable strings are a requirement for SM compatibility or not, but if they aren't, I think we're better off keeping strings immutable. It fits the ES model well and allows for useful simplification of the code.'' | ||
=== Sample instance data === | === Sample instance data === | ||