Serialization of standard JS object types

[Philip Taylor]

To avoid unnecessarily restricting script code, it should be possible for script components to use new Number(42), new String("foo"), etc, and have them correctly (de)serialized with no information loss. ​MDC has a list of the standard classes, and the simple common ones should be supported.

The code for this is currently in CBinarySerializer::HandleScriptVal

[(none)]

Milestone Unclassified deleted

[historic_bruno]

My current idea for implementing this is to call ​JS_GetClass on objects in the serializer, then check the returned class name string for e.g. "Object", "Number", "String". The primitive value for special classes can be retrieved by calling valueOf() or the way I"m testing which is using JS_ValueTo... directly on the object itself. It's straightforward to reconstruct the objects in the deserializer using ​JS_New with the appropriate constructor and passing in the (de)serialized primitive value.

I'd be interested to know if there's a better/more efficient way of checking for standard classes than testing the class name strings. Otherwise, I have a WIP patch that fixes this for Number, String, and Boolean - which I think are the only important ones needing serialization support (other types will be easy to add though).

​Typed arrays are a case not mentioned in this ticket, and require some special handling, but it's not too difficult once you discover the "hidden" API for them. They will also be supported in the patch, both raw buffer objects and arbitrary "data views" should work.

[ben]

In 13429:

Extends binary serializer to support some standard JS classes: Number, String, Boolean. Fixes #406.
Extends binary serializer to support typed arrays.
Extends binary serializer to support custom JS prototype objects in AIs, fixes #407.
Allows full serialization of AIs (not yet implemented). Refs #1089, #1886
Increases binary serializer script backref arena from 8 MB to 16 MB, refs #1842