| Subject: | RFC7159 support: Values as top level entities. |
RFC7159 puts "values" at the top level of the grammar, and values can be objects, arrays, strings, numbers, "null", "true", and "false".
Examples:
my $jn = encode_json(1); # 1
my $js = encode_json("Hello world"); # "Hello world"
my $string = decode_json('"Hello world"'); # Hello world
my $number = decode_json('1'); # 1
The "allow_nonref" configuration option effectively enables this feature for the object-oriented interface to the JSON::PP module, so the code seems to already exist to support this aspect of RFC-7159.
There could be a few possibilities on how this might be handled:
1: Update the docs to state that JSON::PP supports RFC-7159, and change the default behavior to "allow_nonref" enabled. Also document that for RFC-4627 behavior, it is necessary to set "allow_nonref" to disabled.
2: Leave the existing defaults, but update the docs to suggest that for RFC-7159 compliant parsing / encoding, the allow_nonref feature should be turned on.
3: (This could co-exist with either solution 1 or 2): Add an "rfc7159($enable)", and a mutually exclusive "rfc4627($enable)" tag, and throw an exception if both are used at the same time in conflicting ways, or if allow_nonref is used in a conflicting way at the same time.
...just some ideas. Ultimately it's probably best for the JSON family of modules to simply adopt the new standard. It's unlikely to break any existing usage; the RFC was designed for a reasonably painless transition.
Also worth mentioning: ECMA-404 also supports the notion of a 'value' being the top level, where a value can be those things described above: (object, array, string, etc.).