On: Deep cloning objects in JavaScript

[johnfn]

> structuredClone({ a: () => {} })

> VM187:1 Uncaught DOMException: Failed to execute 'structuredClone' on 'Window': () => {} could not be cloned.

Ah, yes. I actually asked this question on StackOverflow 5 years ago [0], and the reason it can't be cloned isn't the worst reason ever... but it basically breaks cloning any non-trivial object. Well, I suppose I'll check back in another 10 years when the next ecmascript proposal around cloning lands...

[0]: https://stackoverflow.com/questions/51939812/how-to-clone-an...

[XeO3 → johnfn]

It is mentioned in the exception list of structuredClone.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

[jauntywundrkind → johnfn]

I disagree that this is trivial.

You have a function, and that function could have local bindings to arbitrary local variables.

[johnfn → jauntywundrkind]

I didn't say that the algorithm was trivial, just that the object was. `{ foo: () => {} }` is a fairly trivial object, all things considered.

[jauntywundrkind → johnfn]

It's not an object. JSON wouldn't cover that. It's code. With code complexity. That's non trivial & you seem to double down on an extensive ask far beyond .odt people's & what the typical need is, in a way that belittles the effort. I don't like how short you are, how you phrase this as some huge weakness. When in fact JSON.stringify/parse - what everyone uses today - have the same object-but-not-code limitations.

[baq → jauntywundrkind]

Functions are first-class objects though…? What’s json got to do with cloning objects except its prevalence as a limited workaround?

[jauntywundrkind → baq]

It's not just an object though. It's an object that has potentially has implicit bindings to something in the rest of the runtime. Bindings that (to my lament) aren't visible in the first clas-object; secret hidden internal state, tying it to the rest of the runtime.

JSON defines what is possible to do that doesn't involve arbitrary bindings to the rest of the runtime. Short of serializing the world, JSON is the best we can do.

It would be possible to try to serialize, and maybe a function is simple enough to serialize. Do we have existing examples of this? There's hundreds of different serialization libraries. For some reason everyone in this thread is super ignoring what seems like a basic widespread limitation, is being condescending to structuredClone, for not doing what no one else does either. Because there's a very good reason: because here be dragons. I don't get why everyone is so combative & aggressive over what seems so clear.

[johnfn → jauntywundrkind]

Why are you talking about JSON? This was a discussion about structuredClone.

> I don't like how short you are, how you phrase this as some huge weakness.

I think you may be reading into my comments more than what is actually there. I think it's a reasonable enough compromise, and I'm happy to have structuredClone.

[dap → jauntywundrkind]

It's been a little while since I wrote JavaScript. Aren't Function objects immutable? Would it not satisfy the desired behavior of clone to reference the same function (not copy it) in the new object?

[eyelidlessness → dap]

Even if functions were immutable as objects, they can reference anything within their containing scope, including arbitrary dynamic variables in outer scopes and even values from other modules (whose bindings are “live”). They may also have their “this” bound to arbitrary objects from any scope at all.

[aragonite → dap]

Function objects are mutable in the sense that you can define new properties for them or assign new values to (writable) existing properties. This is sometimes used to simulate static variables:

  function f() {
    f.count ??= 1;
    console.log(f.count++);
  }
  f(); // Outputs: 1
  f(); // Outputs: 2
  f(); // Outputs: 3

[__s → johnfn]

Consider LJSON: https://github.com/VictorTaelin/LJSON