-
Notifications
You must be signed in to change notification settings - Fork 96
Add failing test for function cloning #329
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@bnoordhuis I just tried latest on Discourse and it is failing due to this test: |
|
Typo? It says |
|
@bnoordhuis sorry about the typo fixed it, but test is still broken due to clone issue |
| console = { | ||
| log: function(...args){ log(args.join(" ")); }, | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what the problem is: the result of this statement is (edit: an object containing) the log function object. The test passes when changed to this:
| console = { | |
| log: function(...args){ log(args.join(" ")); }, | |
| } | |
| console = { | |
| log: function(...args){ log(args.join(" ")); }, | |
| } | |
| undefined |
Let me think what a good solution is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For completeness sake, another workaround is to make the property non-enumerable:
| console = { | |
| log: function(...args){ log(args.join(" ")); }, | |
| } | |
| console = {} | |
| Object.defineProperty(console, "log", {value: function(...args){ log(args.join(" ")); }}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we can just return something here , trouble of crashing on deserialozation boundary is that many eval and don’t care about result , even just saying “function” is fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For posterity, I think there are 4 options:
- do nothing and let the error bubble up (current situation)
- detect the error and return something else, like an empty object or a marker
- deep-copy the object and replace or drop function properties
- ditto but only shallow-copy the object, i.e., fix up only one level
3 is O(n) time and space, 4 is only a partial fix, so I guess 2 is the best option.
Instead of trying to detect upfront if an object can be serialized, just do it and see if it throws a DataCloneError. Unexpected DataCloneErrors were of course already being handled but the new approach does it in a centralized and generic manner. Failed serialization now passes an object with a single "error" string property back to Ruby land. Fixes the failing test from rubyjs#329
Instead of trying to detect upfront if an object can be serialized, just do it and see if it throws a DataCloneError. Unexpected DataCloneErrors were of course already being handled but the new approach does it in a centralized and generic manner. Failed serialization now passes an object with a single "error" string property back to Ruby land. Fixes the failing test from #329
Instead of trying to detect upfront if an object can be serialized, just do it and see if it throws a DataCloneError. Unexpected DataCloneErrors were of course already being handled but the new approach does it in a centralized and generic manner. Failed serialization now passes an object with a single "error" string property back to Ruby land. Fixes the failing test from rubyjs#329
No description provided.