Sigh. I didn’t intend to push that code yet (nor push it directly onto 8.1). Sorry about that.
I agree that it makes sense for the encoder to be common, as I can’t see how a separate encoder would be helpful, unless you’d want to include comments or prefer a certain style unavailable in JSON proper.
The only argument I can think of against your suggestion would be one of discoverability… If JSON5 decoding were enabled via a flag, you’d need to know to look for it whereas most other implementations are in distinct namespaces (partly due to the fact that they’re all independent implementations). Could JSON5.encode() just be an alias for JSON.encode()? Then no flags would be required at all…
Bill
On Dec 23, 2017, at 10:37 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum 10353@lyskom.lysator.liu.se wrote:
I think adding a new module would be easier. The JSON5 format is very permissive and would add many new rules (e.g. identifiers as object keys). I think a new parser (maybe copied from the existing JSON parser) would make it easier to adjust the grammar. I am not sure if you like ragel, but I found it to be very pleasant to work with.
Having taken a quick cursory look at the new JSON5 module, I think it would make sense to have a distinct decoder for JSON5, but have common code for the encoder. Having decode() and validate() call the appropriate implementation depending on flags. This would reduce the amount of code duplication, and ensure that the flags used by the modules stay compatible.
/grubba