The Structured Clone Wars
dean at deanlandolt.com
Fri Jul 15 08:51:54 PDT 2011
> 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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss