ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/JSON-XS/XS.pm
(Generate patch)

Comparing JSON-XS/XS.pm (file contents):
Revision 1.141 by root, Fri Oct 25 19:53:08 2013 UTC vs.
Revision 1.143 by root, Fri Oct 25 20:02:54 2013 UTC

… …
673when there is trailing garbage after the first JSON object, it will 673when there is trailing garbage after the first JSON object, it will
674silently stop parsing there and return the number of characters consumed 674silently stop parsing there and return the number of characters consumed
675so far. 675so far.
676 676
677This is useful if your JSON texts are not delimited by an outer protocol 677This is useful if your JSON texts are not delimited by an outer protocol
678(which is not the brightest thing to do in the first place) and you need
679to know where the JSON text ends. 678and you need to know where the JSON text ends.
680 679
681 JSON::XS->new->decode_prefix ("[1] the tail") 680 JSON::XS->new->decode_prefix ("[1] the tail")
682 => ([], 3) 681 => ([], 3)
683 682
684=back 683=back
… …
778=back 777=back
779 778
780=head2 LIMITATIONS 779=head2 LIMITATIONS
781 780
782All options that affect decoding are supported, except 781All options that affect decoding are supported, except
783C<allow_nonref>. The reason for this is that it cannot be made to 782C<allow_nonref>. The reason for this is that it cannot be made to work
784work sensibly: JSON objects and arrays are self-delimited, i.e. you can concatenate 783sensibly: JSON objects and arrays are self-delimited, i.e. you can
785them back to back and still decode them perfectly. This does not hold true 784concatenate them back to back and still decode them perfectly. This does
786for JSON numbers, however. 785not hold true for JSON numbers, however.
787 786
788For example, is the string C<1> a single JSON number, or is it simply the 787For example, is the string C<1> a single JSON number, or is it simply the
789start of C<12>? Or is C<12> a single JSON number, or the concatenation 788start of C<12>? Or is C<12> a single JSON number, or the concatenation
790of C<1> and C<2>? In neither case you can tell, and this is why JSON::XS 789of C<1> and C<2>? In neither case you can tell, and this is why JSON::XS
791takes the conservative route and disallows this case. 790takes the conservative route and disallows this case.
… …
1006 1005
1007=over 4 1006=over 4
1008 1007
1009=item hash references 1008=item hash references
1010 1009
1011Perl hash references become JSON objects. As there is no inherent ordering 1010Perl hash references become JSON objects. As there is no inherent
1012in hash keys (or JSON objects), they will usually be encoded in a 1011ordering in hash keys (or JSON objects), they will usually be encoded
1013pseudo-random order that can change between runs of the same program but 1012in a pseudo-random order. JSON::XS can optionally sort the hash keys
1014stays generally the same within a single run of a program. JSON::XS can 1013(determined by the I<canonical> flag), so the same datastructure will
1015optionally sort the hash keys (determined by the I<canonical> flag), so 1014serialise to the same JSON text (given same settings and version of
1016the same datastructure will serialise to the same JSON text (given same 1015JSON::XS), but this incurs a runtime overhead and is only rarely useful,
1017settings and version of JSON::XS), but this incurs a runtime overhead 1016e.g. when you want to compare some JSON text against another for equality.
1018and is only rarely useful, e.g. when you want to compare some JSON text
1019against another for equality.
1020 1017
1021=item array references 1018=item array references
1022 1019
1023Perl array references become JSON arrays. 1020Perl array references become JSON arrays.
1024 1021

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines