Existing solutions are changed from escaping to non-escaping, losing flexibility.
I think it would be better to add a switch to control it, but if it is placed in cfg, when traversing characters for escaping, an additional if judgment is required each time. It is better to modify the char2escape table directly, which has better performance.
But this brings a new problem, that is, different cjson objects created by cjson.new() will share this setting. I don't think the problem is big. Most people either turn on or off escaping. It is unlikely that different cjson objects in the same process have two requirements for escaping.
This option(escape_forward_slash) can be regarded as a global option.
Many people are discussing how to solve the forward slash escaping problem, which shows that this is a common demand.
For example: https://github.com/mpx/lua-cjson/pull/57 https://github.com/mpx/lua-cjson/issues/66
Existing solutions are changed from escaping to non-escaping, losing flexibility.
I think it would be better to add a switch to control it, but if it is placed in cfg, when traversing characters for escaping, an additional
ifjudgment is required each time. It is better to modify thechar2escapetable directly, which has better performance.But this brings a new problem, that is, different cjson objects created by
cjson.new()will share this setting. I don't think the problem is big. Most people either turn on or off escaping. It is unlikely that different cjson objects in the same process have two requirements for escaping.This option(
escape_forward_slash) can be regarded as a global option.