Re: The Structured Clone Wars

On Jul 15, 2011, at 1:45 PM, Dean Landolt wrote:

> 
> 
> On Fri, Jul 15, 2011 at 2:50 PM, Allen Wirfs-Brock <allen@wirfs-brock.com> wrote:
> 
> 
> Okay, but what of the assertion itself? Must a cloned JS object must maintain its [[Prototype]]? I'm just curious as to why.

If it is a local clone, yes.  Essential parts of an object's behavior (and even state) may be defined by the objects along its [[Prototype]] chain.  If you eliminate those it isn't behaviorally the same kind of object.

If you are talking about cloning a non-local copy then it depends upon what you are really trying to accomplish.  If you are trying to create a behaviorally equivalent clone in a remote but  similar environment that then you are dealing with some sort of built-in object then maybe you will be satisfied with just connecting to the equivalent built-in pototypes in the remote system (this is essentially what structured clone is doing for well known JS objects like RgExp and Date).  If it is an application defined object with application defined prototypes you may want to first force remote loading of your application so you can connect to it.  Or maybe you want to also serialize the [[Prototype]] chain as part of the remote cloning operation or something else.  May be all you really want do is just clone some static application data without any behavioral component at all (essentially what JSON does).

...
> In either case there are contextual issues such as the [[Prototype]] problem.  More generally if you have a behavioral based (methods+accessors are the only public interface) object model  then you really can't CoW or transfer ownership meaningfully and maintain no shared state illusion. 
> 
> 
> By who's definition of meaningful? IIUC you're asserting that directly sharing context like [[Prototype]] is both important and impossible. I contend that the behavior-based object model can be shared, if only indirectly, by completely detaching it from the main thread's "deeply intertwined, deeply mutable object graph" (to borrow dherman's colorful phrase). This would almost certainly require spec. support but I can think of at least a few ways to do it. If something like this were doable it could open the door for the most efficient structured clone I can think of: no clone at all.

Perhaps, if you had the concept of immutable (and identity free??) behavioral specifications then they could be reified in multiple environment and perhaps sharing an underlying representation.  But that isn't really how JavaScript programs are constructed today.  
..
>   
> 
> Indeed, certain applications may require custom handling. But it would be great if there were an easy and obvious default. It's good enough for JSON, which is a very similar use case (especially in the context of IDB).
> 
> So I'm still curious just how important is it to transmit a faithful representation of an object, prototype and all, for the WebWorker use case? I suspect a few compromises can be made to get to an efficient postMessage that could sidestep Structured Clone entirely. Wouldn't this be a more desirable outcome anyway?
> 

Here's how I'd put it, if JSON is good enough for http server/browser client communications why isn't it good enough for communicating to a Web worker? It seems we would have better scalability if a task  could be fairly transparently assigned to either a local worker or a remote compute server depending upon local capabilities, etc.

My experience (and I've worked with a lot of different OO languages and environments) is that transparent marshalling of object models for either communications or storage seldom ends up being a good long term solution.  It seems very attractive but leads to problems such as schema evolution issues (particularly when long term storage is involved).  Attractive nuance, don't do it :-)