- From: Elliott Sprehn <esprehn@chromium.org>
- Date: Mon, 27 Apr 2015 21:39:40 -0700
- To: Joshua Bell <jsbell@google.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, public-webapps <public-webapps@w3.org>, Katelyn Gadd <kg@luminance.org>, Ted Mielczarek <ted@mozilla.com>, Robin Berjon <robin@w3.org>
- Message-ID: <CAO9Q3iLDDR4DVUkBTqsSg=zyRC-6jVRWQS7HtDEebPU3jEkJYw@mail.gmail.com>
On Apr 24, 2015 3:16 PM, "Joshua Bell" <jsbell@google.com> wrote: > > It seems like the OP's intent is just to deep-copy an object. Something like the OP's tweet... or this, which we use in some tests: > > function structuredClone(o) { > return new Promise(function(resolve) { > var mc = new MessageChannel(); > mc.port2.onmessage = function(e) { resolve(e.data); }; > mc.port1.postMessage(o); > }); > } > > ... but synchronous, which is fine, since the implicit serialization/deserialization needs to be synchronous anyway. > > If we're not dragging in the notion of extensibility, is there complication? I'm pretty sure this would be about a two line function in Blink. That said, without being able to extend it, is it really interesting to developers? The two line function won't be very fast since it'll serialize into a big byte array first since structured clone is for sending objects across threads/processes. It also means going through the runtime API which is slower. That was my point, exposing this naively is just exposing the slow path to developers since a handwritten deep clone will likely be much faster. Developers shouldn't be using structured clone for general deep cloning. TC39 should expose an @@clone callback developers can override for all objects. Indexeddb has a similar situation, there's a comparison function in there that seems super useful since it can compare arrays, but in reality you shouldn't use it for general purpose code. JS should instead add an array compare function, or a general compare function. > > > > On Fri, Apr 24, 2015 at 2:05 PM, Anne van Kesteren <annevk@annevk.nl> wrote: >> >> On Fri, Apr 24, 2015 at 2:08 AM, Robin Berjon <robin@w3.org> wrote: >> > Does this have to be any more complicated than adding a toClone() convention >> > matching the ones we already have? >> >> Yes, much more complicated. This does not work at all. You need >> something to serialize the object so you can transport it to another >> (isolated) global. >> >> >> -- >> https://annevankesteren.nl/ >> >
Received on Tuesday, 28 April 2015 04:40:08 UTC