Re: The Structured Clone Wars

On Fri, Jul 15, 2011 at 1:26 AM, Tom Van Cutsem <tomvc.be@gmail.com> wrote:
> 2011/7/15 Jason Orendorff <jason.orendorff@gmail.com>
>>
>> Back to Mark S. Miller:
>> > And finally there's the issue raised by David on the es-discuss thread:
>> > What
>> > should the structured clone algorithm do when encountering a proxy? The
>> > algorithm as coded below will successfully "clone" proxies, for some
>> > meaning
>> > of clone. Is that the clone behavior we wish for proxies?
>>
>> The structured cloning algorithm should be redefined in terms of the
>> ES object protocol. This seems necessary anyway, for precision.
>>
>> The appropriate behavior regarding proxies would fall out of that;
>> proxies would not have to be specifically mentioned in the algorithm's
>> spec.
>
> +1. This also matches with the behavior of JSON.stringify(aProxy):
> serializing a proxy as data should simply query the object's own properties
> by calling the appropriate traps (in the case of JSON, this includes
> intercepting the call to 'toJSON').

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

Received on Friday, 15 July 2011 17:01:55 UTC