Re: Freezing a regular expression qr()

I can't really tell if what you want is sane, but I found the documentation of JSON::XS to be fairly explicit. If the convert_blessed option is set and an object has a TO_JSON method, that method will be called to convert the object to a string (or whatever).

So, "just" add a TO_JSON method to the Regexp namespace and you can serialize your regular expressions as strings.

#!perl -w
use strict;
use JSON::XS 'encode_json';

print encode_json({foo=>'bar'});

my $j=JSON::XS->new;$j->convert_blessed(1)

print $j->encode({foo=>qr/bar/}); 

sub Regexp::TO_JSON{qq($_[0])}"
[download]

Update:

After discussion of the topic with choroba, I have to add that it is likely a far better approach to explicitly convert your regular expressions to strings manually. As you are generating the data structure, you should also know at which locations there are regular expressions. Convert these to strings.

Also, I want to question the choice of JSON as a serialization format. If you want speed, there are better approaches that allow serializing regular expressions, like Sereal. If you want something human-editable, YAML at least allows comments, which JSON doesn't allow.

Comment on Re: Freezing a regular expression qr() Select or Download Code

Replies are listed 'Best First'.
Re^2: Freezing a regular expression qr() by karlgoethebier (Abbot) on Sep 07, 2017 at 10:00 UTC
"... comments, which JSON doesn't allow." The inevitable addendum: It seems like Cpanel::JSON::XS does: "As a nonstandard extension to the JSON syntax that is enabled by the relaxed setting, shell-style comments are allowed. They can start anywhere outside strings and go till the end of the line." Best regards, Karl ŤThe Crux of the Biscuit is the Apostropheť `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l]
Re^3: Freezing a regular expression qr() by afoken (Chancellor) on Sep 08, 2017 at 06:40 UTC
As a nonstandard extension to the JSON syntax that is enabled by the relaxed setting, shell-style comments are allowed. I don't like that. It feels like an "impedance mismatch". Why on earth would one want to use comment syntax from (unix) shells in something derived from JavaScript? JSON was designed so that you could simply pass it to JavaScript's `eval` function (yes, that would be insecure, but it is possible). Using shell comments breaks that feature. The most natural comment extension for JSON would be JavaScript comments, i.e. from `/` to the next `/` and from `//` to the next end of line. The `//`-style comments have the slight disadvantage of giving some whitespace characters (`\r` and `\n`) a second meaning, whereas pure JSON treats all whitespace characters outside strings equally and allows to freely replace them with other whitespace characters. Apart from shell comments, I can only imagine two more mismatching comment variants: The `REM` keyword, stolen from BASIC and DOS batches. A `C` in the first column of a line, stolen from classic FORTRAN. But while surfing, I found an even more mismatching comment syntax at http://www.gavilan.edu/csis/languages/comments.html: A `*` in column 7 of a line, stolen from COBOL. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]
Re^4: Freezing a regular expression qr() by karlgoethebier (Abbot) on Sep 08, 2017 at 14:33 UTC
"Noli nuntium interficere" Or so. Best regards, Karl ŤThe Crux of the Biscuit is the Apostropheť `perl -MCrypt::CBC -E 'say Crypt::CBC->new(-key=>'kgb',-cipher=>"Blowfish")->decrypt_hex($ENV{KARL});'`Help	[reply] [d/l]


Your skill will accomplish what the force of many cannot
	PerlMonks