JSON.parse should be simple and idiot-proof
isiahmeadows at gmail.com
Sun Oct 21 14:50:15 UTC 2018
Just because something exists doesn't mean it'll be broadly used. Plus,
reviver functions are normally incredibly simple - you don't get enough
context (like key paths) to do anything crazy, and this proposal doesn't
give you enough context for that.
In practice, this changes literally nothing for most consumers, since the
use case is incredibly limited and usually requires server agreement as
well. In fact, that's where my skepticism lies: why add 3 new reviver
parameters when a single "parse ints as bigints" would solve basically the
entire problem? I've yet to see any other use case that couldn't be solved
by manipulating the result after it's parsed.
But personally, I don't see how bugs would be a major issue here
considering its limited utility.
On Sun, Oct 21, 2018 at 02:01 kai zhu <kaizhu256 at gmail.com> wrote:
> wish to express skepticism for the stage-1 proposal "JSON.parse source
> text access" , from web-integration perspective.
> client<->server communications. thankfully, JSON.parse is rarely suspect
> in this process. this proposal however, encourage developers to introduce
> bugs/doubts-of-reliability to JSON.parse, making integration bug-hunting
> more painful than it already is.
> standard-operating-procedure for reviving JSON-data is a 2-step process:
> 1. JSON.parse with zero-config to rule-out bugs during this step
> 2. second-pass of plain-JSON to revive [product-specific] string-encoded
> non-JSON datatypes like BigInt/Date/RegExp, where bugs can be expected
> you normally do not want to complicate bug-hunts by contaminating step-1
> with bugs from step-2.
>  stage-1 proposal - JSON.parse source text access
> kai zhu
> kaizhu256 at gmail.com
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss