Re: The Structured Clone Wars

On Jul 15, 2011, at 10:00 AM, Jonas Sicking wrote:
> Except that you don't want to do that for host objects. Trying to
> clone a File object by cloning its properties is going to give you an
> object which is a whole lot less useful as it wouldn't contain any of
> the file data. Once we define support for cloning ArrayBuffers the
> same thing will apply to it.
> This might in fact be a big hurdle to implementing structured cloning
> in javascript. How would a JS implementation of structured clone
> determine if an object is a host object which would loose all its
> useful semantics if cloned, vs. a "plain" JS object which can usefully
> be cloned?
> / Jonas

And a cloned JS object is a lot less useful if it has lost it's original [[Prototype]]. Generalizations about host objects  are no more or less valid than generalizations about pure JS objects. 

This issue applies to pure JS object graphs or any serialization scheme.  Sometimes language specific physical clones won't capture the desired semantics.  (Consider for example, an object that references a resource by using a symbolic token to access a local resource registry). That is why the ES5 JSON encoder/decoder includes extension points such as the toJSON method.  To enable semantic encodings that are different form the physical object structure. 

The structured clone algorithm, as currently written allows the passing of strings, so it is possible to use in to transmit anything that can be encoded within a string. All it takes needs is an application specific encoder/decoder.  It seems to me the real complication is a desire for some structured clone use cases to avoid serialization and permit sharing via a copy-on-right of a real JS object graph.  If you define this sharing in terms of serialization then you probably eliminate some of the language-specific low level sharing semantic issues.  But you are still going to have higher lever semantic issues such as what does it mean to serialize a File. It isn't clear to me that there is a general solution to the latter.


Received on Friday, 15 July 2011 17:31:39 UTC