Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

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

Report information
The Basics
Id:
98507
Status:
resolved
Priority:
Low/Low
Queue:

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

BugTracker
Severity:
(no value)
Broken in:
(no value)
Fixed in:
(no value)



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.).
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 runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

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