[ViewVC] Diff of: cvs/JSON-XS/XS.pm

Comparing JSON-XS/XS.pm (file contents):
Revision 1.133 by root, Tue Aug 17 23:27:36 2010 UTC vs.
Revision 1.144 by root, Mon Oct 28 23:19:54 2013 UTC

 this module usually compares favourably in terms of speed, too.
 =item * simple to use
 This module has both a simple functional interface as well as an object
-oriented interface interface.
+oriented interface.
 =item * reasonably versatile output formats
 You can choose between the most compact guaranteed-single-line format
 possible (nice for simple line-based protocols), a pure-ASCII format
 package JSON::XS;
 use common::sense;
-our $VERSION = '2.3';
+our $VERSION = 2.34;
 our @ISA = qw(Exporter);
-our @EXPORT = qw(encode_json decode_json to_json from_json);
+our @EXPORT = qw(encode_json decode_json);
-sub to_json($) {
-   require Carp;
-   Carp::croak ("JSON::XS::to_json has been renamed to encode_json, either downgrade to pre-2.0 versions of JSON::XS or rename the call");
-}
-sub from_json($) {
-   require Carp;
-   Carp::croak ("JSON::XS::from_json has been renamed to decode_json, either downgrade to pre-2.0 versions of JSON::XS or rename the call");
-}
 use Exporter;
 use XSLoader;
+use Types::Serialiser ();
 =head1 FUNCTIONAL INTERFACE
 The following convenience methods are provided by this module. They are
 exported by default:
 This function call is functionally identical to:
    $perl_scalar = JSON::XS->new->utf8->decode ($json_text)
 Except being faster.
-=item $is_boolean = JSON::XS::is_bool $scalar
-Returns true if the passed scalar represents either JSON::XS::true or
-JSON::XS::false, two constants that act like C<1> and C<0>, respectively
-and are used to represent JSON C<true> and C<false> values in Perl.
-See MAPPING, below, for more information on how JSON values are mapped to
-Perl.
 =back
 =head1 A FEW NOTES ON UNICODE AND PERL
 If C<$enable> is true (or missing), then the C<encode> method will output JSON objects
 by sorting their keys. This is adding a comparatively high overhead.
 If C<$enable> is false, then the C<encode> method will output key-value
 pairs in the order Perl stores them (which will likely change between runs
-of the same script).
+of the same script, and can change even within the same run from 5.18
+onwards).
 This option is useful if you want the same data structure to be encoded as
 the same JSON text (given the same overall settings). If it is disabled,
 the same hash might be encoded differently even if contains the same data,
 as key-value pairs have no inherent ordering in Perl.
 See SECURITY CONSIDERATIONS, below, for more info on why this is useful.
 =item $json_text = $json->encode ($perl_scalar)
-Converts the given Perl data structure (a simple scalar or a reference
+Converts the given Perl value or data structure to its JSON
-to a hash or array) to its JSON representation. Simple scalars will be
+representation. Croaks on error.
-converted into JSON string or number sequences, while references to arrays
-become JSON arrays and references to hashes become JSON objects. Undefined
-Perl values (e.g. C<undef>) become JSON C<null> values. Neither C<true>
-nor C<false> values will be generated.
 =item $perl_scalar = $json->decode ($json_text)
 The opposite of C<encode>: expects a JSON text and tries to parse it,
 returning the resulting simple scalar or reference. Croaks on error.
-JSON numbers and strings become simple Perl scalars. JSON arrays become
-Perl arrayrefs and JSON objects become Perl hashrefs. C<true> becomes
-C<1>, C<false> becomes C<0> and C<null> becomes C<undef>.
 =item ($perl_scalar, $characters) = $json->decode_prefix ($json_text)
 This works like the C<decode> method, but instead of raising an exception
 when there is trailing garbage after the first JSON object, it will
 silently stop parsing there and return the number of characters consumed
 so far.
 This is useful if your JSON texts are not delimited by an outer protocol
-(which is not the brightest thing to do in the first place) and you need
-to know where the JSON text ends.
+and you need to know where the JSON text ends.
    JSON::XS->new->decode_prefix ("[1] the tail")
    => ([], 3)
 =back
 calls).
 JSON::XS will only attempt to parse the JSON text once it is sure it
 has enough text to get a decisive result, using a very simple but
 truly incremental parser. This means that it sometimes won't stop as
-early as the full parser, for example, it doesn't detect parenthese
+early as the full parser, for example, it doesn't detect mismatched
-mismatches. The only thing it guarantees is that it starts decoding as
+parentheses. The only thing it guarantees is that it starts decoding as
 soon as a syntactically valid JSON text has been seen. This means you need
 to set resource limits (e.g. C<max_size>) to ensure the parser will stop
 parsing in the presence if syntax errors.
 The following methods implement this incremental parser.
 If the method is called in scalar context, then it will try to extract
 exactly I<one> JSON object. If that is successful, it will return this
 object, otherwise it will return C<undef>. If there is a parse error,
 this method will croak just as C<decode> would do (one can then use
-C<incr_skip> to skip the errornous part). This is the most common way of
+C<incr_skip> to skip the erroneous part). This is the most common way of
 using the method.
 And finally, in list context, it will try to extract as many objects
 from the stream as it can find and return them, or the empty list
 otherwise. For this to work, there must be no separators between the JSON
 C<incr_parse> died, in which case the input buffer and incremental parser
 state is left unchanged, to skip the text parsed so far and to reset the
 parse state.
 The difference to C<incr_reset> is that only text until the parse error
-occured is removed.
+occurred is removed.
 =item $json->incr_reset
 This completely resets the incremental parser, that is, after this call,
 it will be as if the parser had never parsed anything.
 =back
 =head2 LIMITATIONS
 All options that affect decoding are supported, except
-C<allow_nonref>. The reason for this is that it cannot be made to
+C<allow_nonref>. The reason for this is that it cannot be made to work
-work sensibly: JSON objects and arrays are self-delimited, i.e. you can concatenate
+sensibly: JSON objects and arrays are self-delimited, i.e. you can
-them back to back and still decode them perfectly. This does not hold true
+concatenate them back to back and still decode them perfectly. This does
-for JSON numbers, however.
+not hold true for JSON numbers, however.
 For example, is the string C<1> a single JSON number, or is it simply the
 start of C<12>? Or is C<12> a single JSON number, or the concatenation
 of C<1> and C<2>? In neither case you can tell, and this is why JSON::XS
 takes the conservative route and disallows this case.
 If the number consists of digits only, JSON::XS will try to represent
 it as an integer value. If that fails, it will try to represent it as
 a numeric (floating point) value if that is possible without loss of
 precision. Otherwise it will preserve the number as a string value (in
 which case you lose roundtripping ability, as the JSON number will be
-re-encoded toa JSON string).
+re-encoded to a JSON string).
 Numbers containing a fractional or exponential part will always be
 represented as numeric (floating point) values, possibly at a loss of
 precision (in which case you might lose perfect roundtripping ability, but
 the JSON number will still be re-encoded as a JSON number).
 Note that precision is not accuracy - binary floating point values cannot
 represent most decimal fractions exactly, and when converting from and to
 floating point, JSON::XS only guarantees precision up to but not including
-the leats significant bit.
+the least significant bit.
 =item true, false
-These JSON atoms become C<JSON::XS::true> and C<JSON::XS::false>,
+These JSON atoms become C<Types::Serialiser::true> and
-respectively. They are overloaded to act almost exactly like the numbers
+C<Types::Serialiser::false>, respectively. They are overloaded to act
-C<1> and C<0>. You can check whether a scalar is a JSON boolean by using
+almost exactly like the numbers C<1> and C<0>. You can check whether
-the C<JSON::XS::is_bool> function.
+a scalar is a JSON boolean by using the C<Types::Serialiser::is_bool>
+function (after C<use Types::Serialier>, of course).
 =item null
 A JSON null atom becomes C<undef> in Perl.
 =over 4
 =item hash references
-Perl hash references become JSON objects. As there is no inherent ordering
+Perl hash references become JSON objects. As there is no inherent
-in hash keys (or JSON objects), they will usually be encoded in a
+ordering in hash keys (or JSON objects), they will usually be encoded
-pseudo-random order that can change between runs of the same program but
+in a pseudo-random order. JSON::XS can optionally sort the hash keys
-stays generally the same within a single run of a program. JSON::XS can
+(determined by the I<canonical> flag), so the same datastructure will
-optionally sort the hash keys (determined by the I<canonical> flag), so
+serialise to the same JSON text (given same settings and version of
-the same datastructure will serialise to the same JSON text (given same
+JSON::XS), but this incurs a runtime overhead and is only rarely useful,
-settings and version of JSON::XS), but this incurs a runtime overhead
+e.g. when you want to compare some JSON text against another for equality.
-and is only rarely useful, e.g. when you want to compare some JSON text
-against another for equality.
 =item array references
 Perl array references become JSON arrays.
 =item other references
 Other unblessed references are generally not allowed and will cause an
 exception to be thrown, except for references to the integers C<0> and
-C<1>, which get turned into C<false> and C<true> atoms in JSON. You can
+C<1>, which get turned into C<false> and C<true> atoms in JSON.
-also use C<JSON::XS::false> and C<JSON::XS::true> to improve readability.
+Since C<JSON::XS> uses the boolean model from L<Types::Serialiser>, you
+can also C<use Types::Serialiser> and then use C<Types::Serialiser::false>
+and C<Types::Serialiser::true> to improve readability.
+   use Types::Serialiser;
-   encode_json [\0, JSON::XS::true]      # yields [false,true]
+   encode_json [\0, Types::Serialiser::true]      # yields [false,true]
-=item JSON::XS::true, JSON::XS::false
+=item Types::Serialiser::true, Types::Serialiser::false
-These special values become JSON true and JSON false values,
+These special values from the L<Types::Serialiser> module become JSON true
-respectively. You can also use C<\1> and C<\0> directly if you want.
+and JSON false values, respectively. You can also use C<\1> and C<\0>
+directly if you want.
 =item blessed objects
 Blessed objects are not directly representable in JSON. See the
 C<allow_blessed> and C<convert_blessed> methods on various options on
 =item C<utf8> flag disabled
 When C<utf8> is disabled (the default), then C<encode>/C<decode> generate
 and expect Unicode strings, that is, characters with high ordinal Unicode
 values (> 255) will be encoded as such characters, and likewise such
-characters are decoded as-is, no canges to them will be done, except
+characters are decoded as-is, no changes to them will be done, except
 "(re-)interpreting" them as Unicode codepoints or Unicode characters,
 respectively (to Perl, these are the same thing in strings unless you do
 funny/weird/dumb stuff).
 This is useful when you want to do the encoding yourself (e.g. when you
 well - using C<eval> naively simply I<will> cause problems.
 Another problem is that some javascript implementations reserve
 some property names for their own purposes (which probably makes
 them non-ECMAscript-compliant). For example, Iceweasel reserves the
-C<__proto__> property name for it's own purposes.
+C<__proto__> property name for its own purposes.
 If that is a problem, you could parse try to filter the resulting JSON
 output for these property strings, e.g.:
    $json =~ s/"__proto__"\s*:/"__proto__renamed":/g;
 This works because C<__proto__> is not valid outside of strings, so every
-occurence of C<"__proto__"\s*:> must be a string used as property name.
+occurrence of C<"__proto__"\s*:> must be a string used as property name.
 If you know of other incompatibilities, please let me know.
 =head2 JSON and YAML
 that difficult or long) and finally make YAML compatible to it, and
 educating users about the changes, instead of spreading lies about the
 real compatibility for many I<years> and trying to silence people who
 point out that it isn't true.
-Addendum/2009: the YAML 1.2 spec is still incomaptible with JSON, even
+Addendum/2009: the YAML 1.2 spec is still incompatible with JSON, even
-though the incompatibilities have been documented (and are known to
+though the incompatibilities have been documented (and are known to Brian)
-Brian) for many years and the spec makes explicit claims that YAML is a
+for many years and the spec makes explicit claims that YAML is a superset
-superset of JSON. It would be so easy to fix, but apparently, bullying and
+of JSON. It would be so easy to fix, but apparently, bullying people and
 corrupting userdata is so much easier.
 =back
 are browser design bugs, but it is still you who will have to deal with
 it, as major browser developers care only for features, not about getting
 security right).
+=head1 INTEROPERABILITY WITH OTHER MODULES
+C<JSON::XS> uses the L<Types::Serialiser> module to provide boolean
+constants. That means that the JSON true and false values will be
+comaptible to true and false values of iother modules that do the same,
+such as L<JSON::PP> and L<CBOR::XS>.
 =head1 THREADS
 This module is I<not> guaranteed to be thread safe and there are no
 plans to change this until Perl gets thread support (as opposed to the
 horribly slow so-called "threads" which are simply slow and bloated
 process simulations - use fork, it's I<much> faster, cheaper, better).
 (It might actually work, but you have been warned).
+=head1 THE PERILS OF SETLOCALE
+Sometimes people avoid the Perl locale support and directly call the
+system's setlocale function with C<LC_ALL>.
+This breaks both perl and modules such as JSON::XS, as stringification of
+numbers no longer works correctly (e.g. C<$x = 0.1; print "$x"+1> might
+print C<1>, and JSON::XS might output illegal JSON as JSON::XS relies on
+perl to stringify numbers).
+The solution is simple: don't call C<setlocale>, or use it for only those
+categories you need, such as C<LC_MESSAGES> or C<LC_CTYPE>.
+If you need C<LC_NUMERIC>, you should enable it only around the code that
+actually needs it (avoiding stringification of numbers), and restore it
+afterwards.
 =head1 BUGS
 While the goal of this module is to be correct, that unfortunately does
 not mean it's bug-free, only that I think its design is bug-free. If you
 keep reporting bugs they will be fixed swiftly, though.
 Please refrain from using rt.cpan.org or any other bug reporting
 service. I put the contact address into my modules for a reason.
 =cut
-our $true  = do { bless \(my $dummy = 1), "JSON::XS::Boolean" };
+BEGIN {
-our $false = do { bless \(my $dummy = 0), "JSON::XS::Boolean" };
+   *true    = \$Types::Serialiser::true;
+   *true    = \&Types::Serialiser::true;
+   *false   = \$Types::Serialiser::false;
+   *false   = \&Types::Serialiser::false;
+   *is_bool = \&Types::Serialiser::is_bool;
-sub true()  { $true  }
+   *JSON::XS::Boolean:: = *Types::Serialiser::Boolean::;
-sub false() { $false }
-sub is_bool($) {
-   UNIVERSAL::isa $_[0], "JSON::XS::Boolean"
-#      or UNIVERSAL::isa $_[0], "JSON::Literal"
 }
 XSLoader::load "JSON::XS", $VERSION;
-package JSON::XS::Boolean;
-use overload
-   "0+"     => sub { ${$_[0]} },
-   "++"     => sub { $_[0] = ${$_[0]} + 1 },
-   "--"     => sub { $_[0] = ${$_[0]} - 1 },
-   fallback => 1;
-1;
 =head1 SEE ALSO
 The F<json_xs> command line utility for quick experiments.
  Marc Lehmann <schmorp@schmorp.de>
  http://home.schmorp.de/
 =cut
+1

Diff Legend

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

Comparing JSON-XS/XS.pm (file contents): Revision 1.133 by root, Tue Aug 17 23:27:36 2010 UTC vs. Revision 1.144 by root, Mon Oct 28 23:19:54 2013 UTC

Diff Legend

Comparing JSON-XS/XS.pm (file contents):
Revision 1.133 by root, Tue Aug 17 23:27:36 2010 UTC vs.
Revision 1.144 by root, Mon Oct 28 23:19:54 2013 UTC