On Fri, Jul 15, 2011 at 1:00 PM, Jonas Sicking <jonas@sicking.cc> wrote:

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?

Through the use of a serializable predicate -- perhaps toJSON, as you recognized in your response Dave's referenced post. Is it really a problem if host objects don't survive in full across serialization boundaries? As you say "All APIs that use structured cloning are pretty explicit. Things like Worker.postMessage and IDBObjectStore.put pretty explicitly creates a new copy." If you expect host objects to survive across that boundary you'll quickly learn otherwise, and it won't take long to grok the difference.

Java draws a distinction between marshalling and serialization which might be useful to this discussion:

http://tools.ietf.org/html/rfc2713#section-2.3

To "marshal" an object means to record its state and codebase(s) insuch a way that when the marshalled object is "unmarshalled," a copy of the original object is obtained, possibly by automatically loading the class definitions of the object. You can marshal any object that is serializable or remote (that is, implements the java.rmi.Remote interface). Marshalling is like serialization, except marshalling also records codebases.

I agree with the conclusion in Dave's post:

A more adaptable approach might be for ECMAScript to specify “transmittable” data structures.

But the premise suggests the need for marshalling where we can get by without preserving all this environment information. If you don't like the behavior toJSON is already metaprogrammable, and as Allen suggests a schema could be used to capture deeper type information -- it could also communicate property descriptor config. I'd rather a fully self-describing format exist but I concede it's unnecessary.