On Jul 15, 2011, at 1:45 PM, Dean Landolt wrote:
>
>
> On Fri, Jul 15, 2011 at 2:50 PM, Allen Wirfs-Brock <[email protected]>
> 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 :-)
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
