sub sortByDate
{
#get dates. will look like this: date:"2015-02-16", "YYYY-MM-DD",
my $aDate = $a =~ /date:\"(\d{4}\-\d{2}\-\d{2})"/;
my $bDate = $b =~ /date:\"(\d{4}\-\d{2}\-\d{2})"/;
return ($aDate cmp $bDate);
}
...should contain...
my($aDate) = $a =~ /date\"(\d{4}-\d{2}-\d{2})"/;
my($bDate) = $b =~ /date\"(\d{4}-\d{2}-\d{2})"/;
The regexp binding operator returns true/false (1 or 0) in scalar context, and the match contents in list context. The parens around your variable names place the return value of the =~ operator into list context.
By the way, even for small bits of JSON, I'd be inclined to convert them to a datastructure as the first thing I do, rather than treating the json as text.
Update: An example of treating the data as JSON:
use strict;
use warnings;
use JSON;
use Data::Dump;
my @data;
while (<DATA>) {
next unless /\N/;
push @data, decode_json($_);
}
print "Unsorted:\n";
dd \@data;
my @sorted = sort { $a->{date} cmp $b->{date} } @data;
print "\nSorted:\n";
dd \@sorted;
__DATA__
{ "date":"2015-03-01", "content":"asdf" }
{ "date":"2015-05-01", "content":"erwa" }
{ "date":"2015-01-02", "content":"erts" }
{ "date":"2014-04-02", "content":"w34r" }
...produces the following output:
Unsorted:
[
{ content => "asdf", date => "2015-03-01" },
{ content => "erwa", date => "2015-05-01" },
{ content => "erts", date => "2015-01-02" },
{ content => "w34r", date => "2014-04-02" },
]
Sorted:
[
{ content => "w34r", date => "2014-04-02" },
{ content => "erts", date => "2015-01-02" },
{ content => "asdf", date => "2015-03-01" },
{ content => "erwa", date => "2015-05-01" },
]
I did have to fix up your JSON, but I assume the real data you are working with is real JSON, not pseudo-JSON as the post seems to show. There are many reasons why I would prefer an approach that treats the input JSON as JSON rather than as strings, including:
- Easy detection of malformed input.
- As the input grows more complex, the solution scales up to encapsulate the complexity; you don't have to invent a new regexp every time the data takes a new turn.
- It's more convenient to deal with data structures internally. We should favor approaches that convert to the most convenient format as early as possible, and convert away from that most convenient format as late as possible... if we value reduced code complexity and fewer bugs.
- Someone has already written a JSON parser; you don't need to.
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.