> > > 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
