4 ms·

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

by johnfn 3y ago

> 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-object-with-an-arrow-function-in-javascript https://stackoverflow.com/questions/51939812/how-to-clone-an...

jauntywundrkind 3y ago
I disagree that this is trivial. You have a function, and that function could have local bindings to arbitrary local variables.
- johnfn 3y ago
  I didn't say that the algorithm was trivial, just that the object was. `{ foo: () => {} }` is a fairly trivial object, all things considered.
  - jauntywundrkind 3y ago
    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 3y ago
      Functions are first-class objects though…? What’s json got to do with cloning objects except its prevalence as a limited workaround?
      - jauntywundrkind 3y ago
        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 3y ago
      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 3y ago
  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?
  - aragonite 3y ago
    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
  - eyelidlessness 3y ago
    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.
XeO3 3y ago
It is mentioned in the exception list of structuredClone. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#things_that_dont_work_with_structured_clone https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
__s 3y ago
Consider LJSON: https://github.com/VictorTaelin/LJSON https://github.com/VictorTaelin/LJSON

by johnfn 3y ago

jauntywundrkind 3y ago

I disagree that this is trivial. You have a function, and that function could have local bindings to arbitrary local variables.

johnfn 3y ago
I didn't say that the algorithm was trivial, just that the object was. `{ foo: () => {} }` is a fairly trivial object, all things considered.
- jauntywundrkind 3y ago
  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 3y ago
    Functions are first-class objects though…? What’s json got to do with cloning objects except its prevalence as a limited workaround?
    - jauntywundrkind 3y ago
      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 3y ago
    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 3y ago
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?
- aragonite 3y ago
  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
- eyelidlessness 3y ago
  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.

XeO3 3y ago

It is mentioned in the exception list of structuredClone. https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Structured_clone_algorithm#things_that_dont_work_with_structured_clone https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

__s 3y ago

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