Skip Menu |
 

This queue is for tickets about the JSON-PP CPAN distribution.

Report information
The Basics
Id: 98507
Status: resolved
Priority: 0/
Queue: JSON-PP

People
Owner: Nobody in particular
Requestors: davido [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: RFC7159 support: Values as top level entities.
Download (untitled) / with headers
text/plain 1.5k
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.).
Download (untitled) / with headers
text/plain 1.7k
On Tue Sep 02 00:24:27 2014, DAVIDO wrote: Show quoted text
> 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.).
Closed this too. Thanks.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.