Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307)

> Is there a concern that JSON.parse/stringify behavior isn't precisely specified

No.  But note that this spec never invokes JSON.parse/stringify.  See also https://github.com/w3c/browser-payment-api/issues/338

> From a naive skim of those specs it seems to me like they do precisely define which "objects can be serialized to a string using JSON.stringify and later deserialized back to an object using JSON.parse with no loss of data"

It really depends on your definition of "loss of data".

> but I suspect we can all agree on what that algorithm would be

Maybe.  See thread starting at https://lists.w3.org/Archives/Public/public-script-coord/2016OctDec/0071.html if you haven't seen it yet.

> FWIW the blink implementation appears to rely just on our JSON.stringify method succeeding

Note that invoking JSON.stringify has side-effects, so if the intent is that it be invoked then the spec has to say _exactly_ when that happens.  The spec clearly doesn't do that.

My post in the above linked public-script-coord thread attempts to outline a partial (necessary by not sufficient) test for a side-effect-free definition of "no loss of data", but as I note in that thread it's not only hard to specify but probably doesn't actually produce behavior anyone wants.

> Cases where stringify generates a string which will fail to parse

Can't happen.

> Cases where stringify generates a string which, when parsed, produces an object graph that doesn't contain all the properties of the original.

This really depends on how you define "properties".  For example, stringify followed by parse will change your prototypes if you the parse in a different global from the stringify...  Should that count?  Probably not.

> Cases where round-tripping via stringify and parse produce an object with different values. Eg. [undefined] stringifys to [null].

Lots of those cases, yes.

> Perhaps the primary issue for the WG here is conformance testing?

The primary issue is that the behavior is NOT DEFINED.

> The value must satisfy:

These are not nearly enough; see the public-script-coord spec.

> there are no cycles

This is not an invariant of the object graph, when proxies are involved.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/307#issuecomment-263952280