Re: Exposing structured clone as an API?
On Sat, Apr 25, 2015 at 12:41 AM, Brendan Eich bren...@secure.meer.net wrote: Step where you need to, to avoid falling over :-P. Fair. I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28566 on adding a structured clone API. The problems with generalized/extensible clone are clear but we have structured clone already. It is based on a hardcoded type-case statement. It could be improved a bit without trying to solve all possible problems, IMHO. Dmitry and I worked a bit on https://github.com/dslomov-chromium/ecmascript-structured-clone at some point to clean up things and integrate it with ECMAScript, but it hasn't really gone anywhere so far. -- https://annevankesteren.nl/
Re: Exposing structured clone as an API?
On Apr 24, 2015 3:16 PM, Joshua Bell jsb...@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 ann...@annevk.nl
wrote:
On Fri, Apr 24, 2015 at 2:08 AM, Robin Berjon ro...@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/
Re: Exposing structured clone as an API?
On Thu, Apr 23, 2015 at 6:31 PM, Kyle Huey m...@kylehuey.com wrote: On Thu, Apr 23, 2015 at 6:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/23/15 6:34 PM, Elliott Sprehn wrote: Have you benchmarked this? I think you're better off just writing your own clone library. That requires having a list of all objects browsers consider clonable and having ways of cloning them all, right? Maintaining such a library is likely to be a somewhat demanding undertaking as new clonable objects are added... -Boris Today it's not demanding, it's not even possible. e.g. how do you duplicate a FileList object? We should just fix [1] and get rid of the FileList interface. Are there more interfaces this applies to? [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23682 / Jonas
Re: Exposing structured clone as an API?
On 24/04/2015 02:18 , Anne van Kesteren wrote: On Thu, Apr 23, 2015 at 3:02 PM, Ted Mielczarek t...@mozilla.com wrote: Has anyone ever proposed exposing the structured clone algorithm directly as an API? There has been some talk about moving structured cloning into ECMAScript proper and exposing the primitives. But TC39 does not seem particularly receptive unless it comes with a way for someone to participate in the structured cloning algorithm with custom objects. Does this have to be any more complicated than adding a toClone() convention matching the ones we already have? -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Exposing structured clone as an API?
Step where you need to, to avoid falling over :-P. The problems with generalized/extensible clone are clear but we have structured clone already. It is based on a hardcoded type-case statement. It could be improved a bit without trying to solve all possible problems, IMHO. /be Anne van Kesteren wrote: On Fri, Apr 24, 2015 at 3:13 PM, Joshua Belljsb...@google.com wrote: If we're not dragging in the notion of extensibility, is there complication? I would be fine with adding an API without extensibility. I was just afraid we might step on TC39's toes, but maybe since they're not helping out with structured clones that's okay?
Re: Exposing structured clone as an API?
On Fri, Apr 24, 2015 at 3:13 PM, Joshua Bell jsb...@google.com wrote: If we're not dragging in the notion of extensibility, is there complication? I would be fine with adding an API without extensibility. I was just afraid we might step on TC39's toes, but maybe since they're not helping out with structured clones that's okay? -- https://annevankesteren.nl/
Re: Exposing structured clone as an API?
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?
On Fri, Apr 24, 2015 at 2:05 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Fri, Apr 24, 2015 at 2:08 AM, Robin Berjon ro...@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/
Re: Exposing structured clone as an API?
On Fri, Apr 24, 2015 at 2:08 AM, Robin Berjon ro...@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/
Re: Exposing structured clone as an API?
On 23 April 2015 at 15:02, Ted Mielczarek t...@mozilla.com wrote:
Has anyone ever proposed exposing the structured clone algorithm directly as
an API?
If you didn't just do so, I will :)
1. https://twitter.com/TedMielczarek/status/591315580277391360
Looking at your jsfiddle, here's a way to turn that into something useful.
+Object.prototype.clone = Object.prototype.clone || function() {
- function clone(x) {
return new Promise(function (resolve, reject) {
window.addEventListener('message', function(e) {
resolve(e.data);
});
+window.postMessage(this, *);
-window.postMessage(x, *);
});
}
But are we are in the wrong place to have that discussion?
Re: Exposing structured clone as an API?
On Apr 23, 2015, at 3:27 PM, Martin Thomson martin.thom...@gmail.com wrote:
On 23 April 2015 at 15:02, Ted Mielczarek t...@mozilla.com wrote:
Has anyone ever proposed exposing the structured clone algorithm directly as
an API?
If you didn't just do so, I will :)
1. https://twitter.com/TedMielczarek/status/591315580277391360
Looking at your jsfiddle, here's a way to turn that into something useful.
+Object.prototype.clone = Object.prototype.clone || function() {
- function clone(x) {
return new Promise(function (resolve, reject) {
window.addEventListener('message', function(e) {
resolve(e.data);
});
+window.postMessage(this, *);
-window.postMessage(x, *);
});
}
But are we are in the wrong place to have that discussion?
Code nitpick: it probably should remove the event listener from within the
handler, or calling this function repeatedly will leak memory. Also it will get
slower every time.
Actually, now that I think about it, this isn’t usable at all if you are using
postMessage for anything else, since you could accidentally capture
non-cloning-related messages.
I guess these are potentially arguments to expose cloning directly.
Regards,
Maciej
Exposing structured clone as an API?
Has anyone ever proposed exposing the structured clone algorithm directly as an API? Katelyn Gadd was musing about fast deep copy in JS on Twitter, and I proposed a hack to use postMessage to do so[1], which works but it's a little roundabout. Since structured clone is a primitive that the web platform is built on it seems like a primitive that ought to be exposed. I know this exists in other languages (Python has copy.deepcopy[2]) and there's an npm deepcopy module[3] with lots of downloads so this is clearly something people use. -Ted 1. https://twitter.com/TedMielczarek/status/591315580277391360 2. https://docs.python.org/2/library/copy.html#copy.deepcopy 3. https://www.npmjs.com/package/deepcopy
Re: Exposing structured clone as an API?
On 23 April 2015 at 15:34, Elliott Sprehn espr...@chromium.org wrote: Have you benchmarked this? I think you're better off just writing your own clone library. Not really the point of my mail. Of course you would be better writing a real clone. It could probably even be synchronous, though it removes this (or a less bad version, see Maceij's comments) as a polyfill option.
Re: Exposing structured clone as an API?
The way many browsers implement this isn't going to be particularly fast.
It serializes the objects to a byte sequence so it can be transferred to
another thread or process and then inflates the objects on the other side.
Have you benchmarked this? I think you're better off just writing your own
clone library.
On Apr 23, 2015 12:30 PM, Martin Thomson martin.thom...@gmail.com wrote:
On 23 April 2015 at 15:02, Ted Mielczarek t...@mozilla.com wrote:
Has anyone ever proposed exposing the structured clone algorithm
directly as an API?
If you didn't just do so, I will :)
1. https://twitter.com/TedMielczarek/status/591315580277391360
Looking at your jsfiddle, here's a way to turn that into something useful.
+Object.prototype.clone = Object.prototype.clone || function() {
- function clone(x) {
return new Promise(function (resolve, reject) {
window.addEventListener('message', function(e) {
resolve(e.data);
});
+window.postMessage(this, *);
-window.postMessage(x, *);
});
}
But are we are in the wrong place to have that discussion?
Re: Exposing structured clone as an API?
On Thu, Apr 23, 2015 at 6:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/23/15 6:34 PM, Elliott Sprehn wrote: Have you benchmarked this? I think you're better off just writing your own clone library. That requires having a list of all objects browsers consider clonable and having ways of cloning them all, right? Maintaining such a library is likely to be a somewhat demanding undertaking as new clonable objects are added... -Boris Today it's not demanding, it's not even possible. e.g. how do you duplicate a FileList object? - Kyle
Re: Exposing structured clone as an API?
On 4/23/15 9:31 PM, Kyle Huey wrote: Today it's not demanding, it's not even possible. e.g. how do you duplicate a FileList object? Ah, there we go. I figured there was something that would fail the ways of cloning them all test in the platform today... ;) We should make it possible to manually clone FileList of course, but the larger point is that this is likely to continue being a problem. -Boris
Re: Exposing structured clone as an API?
On 4/23/15 6:34 PM, Elliott Sprehn wrote: Have you benchmarked this? I think you're better off just writing your own clone library. That requires having a list of all objects browsers consider clonable and having ways of cloning them all, right? Maintaining such a library is likely to be a somewhat demanding undertaking as new clonable objects are added... -Boris
Re: Exposing structured clone as an API?
On Thu, Apr 23, 2015 at 3:02 PM, Ted Mielczarek t...@mozilla.com wrote: Has anyone ever proposed exposing the structured clone algorithm directly as an API? There has been some talk about moving structured cloning into ECMAScript proper and exposing the primitives. But TC39 does not seem particularly receptive unless it comes with a way for someone to participate in the structured cloning algorithm with custom objects. But yeah, I think this should definitely be an API of sorts eventually. -- https://annevankesteren.nl/
