As rightly pointed out in https://github.com/ungap/raw-json/issues/3 a Map as context was a bad idea due possible collision with numbers rounded to their nearest most representative value:
9007199254740993 === 9007199254740992
// true
Pre-producing context references on already parsed values was not the way to go so that here:
the original text inverts all primitives:
strings become the only number in the JSON
booleans, numbers and null become the only strings
while revived:
values with typeof numbers returns as source string
all strings and newly retrieved numbers as string are parsed as value and the source becomes free
I took the opportunity to also remove Reflect.apply as all I need is call and everything I've said in here still remains ... TL;DR I don't care about poisoned envs because it's not in this ponyfill that such issue can be solved and if Function.prototype.call has been poisoned anyone would have a way bigger issue to tackle in production. That being said, guards against sloppy JSON API remain so it's a win-win and "secure" as meant by MDN
added tests that show correct results in bun and ponyfilled JSON
TODO ???
There's possible room to improve repeated sources parsing via an extra map but the current logic is nearly as fast as native Chrome/ium implementation so it'd be probably premature optimization but surely something to keep in mind if anyone would claim faster results ... although I also need to measure that would be the case as it needs O(2) operations (has + get or set because just get might be falsy for false or null or 0)
As rightly pointed out in https://github.com/ungap/raw-json/issues/3 a Map as context was a bad idea due possible collision with numbers rounded to their nearest most representative value:
Pre-producing context references on already parsed values was not the way to go so that here:
Reflect.apply
as all I need iscall
and everything I've said in here still remains ... TL;DR I don't care about poisoned envs because it's not in this ponyfill that such issue can be solved and ifFunction.prototype.call
has been poisoned anyone would have a way bigger issue to tackle in production. That being said, guards against sloppy JSON API remain so it's a win-win and "secure" as meant by MDNTODO ???
There's possible room to improve repeated sources parsing via an extra map but the current logic is nearly as fast as native Chrome/ium implementation so it'd be probably premature optimization but surely something to keep in mind if anyone would claim faster results ... although I also need to measure that would be the case as it needs
O(2)
operations (has + get or set because just get might be falsy forfalse
ornull
or0
)