On Jul 15, 2011, at 8:51 AM, Dean Landolt wrote: >> >> It's serialization. >> >> Or, it's a spec fiction to explain and codify the Web-visible effects >> of serialization and deserialization without specifying a >> serialization format. > > > As such, it seem like this may be a poor specification approach. Translation > to/from a static serialization format would make clear that there is no > sharing of any active object mechanisms such as prototype objects. This is > not clear in the current specification. If the specification did use an > explicit serialization format in this manner then certainly a valid > optimization in appropriate situations would be for an implementation to > eliminate the actual encoding/decoding of the serialized representation and > to directly generate the target objects. However, by specifying it terms of > such a format you would precisely define the required transformation. > > If you didn't want to be bothered with inventing a serialization format > solely for specification purposes you could accomplish the same thing by > specify structured clone as if it was a transformation to/from JSON format > > > JSON alone may not be enough, but it shouldn't be too troublesome to specify > a slightly enhanced es-specific JSON extension that includes serializations > for undefined, NaN, Infinity, -Infinity, etc. And naturally, support for > Date, RegExp and Function would be a huge boon. If a referencing technique > were addressed this could even include a <| equivalent to address the > [[Prototype]] issue Allen mentioned. > > In this context some of the limitations intentionally imposed in JSON are > unnecessary, so why saddle the web platform with them? A more expressive > standardized serialization would be useful across the board.
JSON + an appropiate schema is enough. You can define a JSON encoded schema that deals with undefined, NaN, etc. as well as circular object references, property attributes, and other issues. For example see https://github.com/allenwb/jsmirrors/blob/master/jsonObjSample.js for a sketch of such a schema. For structured clone usage cases that is all you need. I'm less convinced that one standardized universal JS object serialization format is such a good idea. There are lots of application specific issues involved in object serialization and to create a universal format/serializer/deserializer you have to make the policy that are applied highly parameterized. I think it might be better to leave that problem to library writers. Allen
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
