To the extent that you use `JSON.stringify`, I hope you're specific to refer to "the original value of" it, to be clear that monkey-patching doesn't affect it. Or, if you do want overwriting the `stringify` property of the `JSON` object to have this effect, then being clear about that in the spec would be good as well. The cleanest way layering-wise to refer into the ECMAScript spec would be a slight refactoring into an "abstract operation" that can't be overwritten. cc @domenic who has done a number of these layering adjustments in the past. I agree with @bzbarsky that ECMAScript doesn't really define the machinery to detect without side effects whether an object is JSON-stringifyable as defined above. It is potentially possible to define it, but it would be pretty ugly (violating some invariants that we try to maintain about the JS object model) and a lot of work to get right. Given that users already have to worry about losing data when calling JSON.stringify directly, how much worse is it that they may also encounter that issue in this case? Is this part of the API already shipped to users in some browsers? If so, compatibility would be a pretty strong reason to continue taking an object as input, to be serialized to JSON, rather than a string, even if it's not conceptually the cleanest model. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/w3c/browser-payment-api/issues/307#issuecomment-265386312
Received on Wednesday, 7 December 2016 08:29:02 UTC