4 ms·

It doesn't "corrupt" them; it converts them to JSON strings. It's in the name. Expecting `JSON.stringify` to throw in those situations would be like expecting `

It doesn't "corrupt" them; it converts them to JSON strings. It's in the name. Expecting `JSON.stringify` to throw in those situations would be like expecting `str` in Python to throw.

mike_hock 3y ago
`str` is the equivalent of `toString`, not of `JSON.stringify`. Failure of a serializer-deserializer to roundtrip properly is corruption. The poorly chosen name (which is usually called "dump" or "serialize" in other languages) does not give license for silent corruption.
- jay_kyburz 3y ago
  "stringify" sound more like toString than serialize to me.
  - anamexis 3y ago
    I think that is the issue.
    - baq 3y ago
      I agree with everyone here: it’s named correctly, but other languages did it… differently. (Stopping short of “better”, but only just.)
    - randomdata 3y ago
      That is the solution. It allows JSON.serialize to exhibit the non-corrupting behaviour, giving a reasonable indication to the developer which is which by the name alone. The issue, if there is one, is that nobody ever got around to implementing JSON.serialize.
      - accrual 3y ago
        If a JSON.serialize function did exist, would it do the same thing as JSON.stringify, just with catchable exceptions when one tries to serialize something that can't be (e.g. functions, date objects)?
xpressvideoz 3y ago
It does not convert them to JSON strings, as stated in the original article. That's why I said it corrupted the values. > JSON.stringify({a: ()=>{}}) {} > JSON.stringify({a: /b/}) {"a":{}}
- wfhBrian 3y ago
  You can use a replacer function to special handle stringifying functions if you needed to do that.
  - xpressvideoz 3y ago
    What irks me is its default behavior. A function should do safe operations by default. Compared to `JSON.stringify()`, 'structuredClone()` throws an error when it encounters values that cannot be cloned, which is a much saner approach. Probably because they learned from the mistake.
    - shrew 3y ago
      I understand your point and I can’t deny that Javascript continues to introduce weird, silent failures and quirks even today when everything is a bit more thought out than “the bad old days”. But I think in the case of JSON.stringify it’s more about use case. 99% of the time, users of this method are taking some data and serialising it to a JSON compliant form to send to the server. JSON doesn’t support functions, or complex objects like a Date, so I tend to think it’s a reasonable default that functions disappear and Date’s are converted to an ISO standard. To insist that every single user runs a preparation step that strips out unserialisability data and chooses how to handle Date objects sounds laborious, error prone, and ripe for another npm dependency everyone suddenly normalises for every project. Maybe a “strict mode” of some sort where you could have it throw on anything for cases where you need to guarantee everything is being sent? OTOH, I have to concede that while this method has silent failures, they then implemented JSON.parse to throw at the slightest issue. So I have to admit there’s consistency even within the API.
      - 3y ago

It doesn't "corrupt" them; it converts them to JSON strings. It's in the name. Expecting `JSON.stringify` to throw in those situations would be like expecting `str` in Python to throw.

mike_hock 3y ago

`str` is the equivalent of `toString`, not of `JSON.stringify`. Failure of a serializer-deserializer to roundtrip properly is corruption. The poorly chosen name (which is usually called "dump" or "serialize" in other languages) does not give license for silent corruption.

jay_kyburz 3y ago
"stringify" sound more like toString than serialize to me.
- anamexis 3y ago
  I think that is the issue.
  - baq 3y ago
    I agree with everyone here: it’s named correctly, but other languages did it… differently. (Stopping short of “better”, but only just.)
  - randomdata 3y ago
    That is the solution. It allows JSON.serialize to exhibit the non-corrupting behaviour, giving a reasonable indication to the developer which is which by the name alone. The issue, if there is one, is that nobody ever got around to implementing JSON.serialize.
    - accrual 3y ago
      If a JSON.serialize function did exist, would it do the same thing as JSON.stringify, just with catchable exceptions when one tries to serialize something that can't be (e.g. functions, date objects)?

xpressvideoz 3y ago

It does not convert them to JSON strings, as stated in the original article. That's why I said it corrupted the values. > JSON.stringify({a: ()=>{}}) {} > JSON.stringify({a: /b/}) {"a":{}}

wfhBrian 3y ago
You can use a replacer function to special handle stringifying functions if you needed to do that.
- xpressvideoz 3y ago
  What irks me is its default behavior. A function should do safe operations by default. Compared to `JSON.stringify()`, 'structuredClone()` throws an error when it encounters values that cannot be cloned, which is a much saner approach. Probably because they learned from the mistake.
  - shrew 3y ago
    I understand your point and I can’t deny that Javascript continues to introduce weird, silent failures and quirks even today when everything is a bit more thought out than “the bad old days”. But I think in the case of JSON.stringify it’s more about use case. 99% of the time, users of this method are taking some data and serialising it to a JSON compliant form to send to the server. JSON doesn’t support functions, or complex objects like a Date, so I tend to think it’s a reasonable default that functions disappear and Date’s are converted to an ISO standard. To insist that every single user runs a preparation step that strips out unserialisability data and chooses how to handle Date objects sounds laborious, error prone, and ripe for another npm dependency everyone suddenly normalises for every project. Maybe a “strict mode” of some sort where you could have it throw on anything for cases where you need to guarantee everything is being sent? OTOH, I have to concede that while this method has silent failures, they then implemented JSON.parse to throw at the slightest issue. So I have to admit there’s consistency even within the API.
    - 3y ago