Re: The Structured Clone Wars

>
>
> 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.