sub Clear_MakePtag
{
     return join ("\r\n",
                  map  { "<p>$_</p>" }
                  grep { /\S/ }
                  split ("\r\n", my ($fix) = @_)
     );
}

sub MakePtag
{
     my ($fix) = @_;

     $fix =~ s!\r\n$!!s;
     $fix =~ s!\r\n!</p>\r\n<p>!g;

     return "<p>$fixme</p>";   
}
[download]

update: In the original node, I'm probably not as clear I should be that much of the second sub is ovid's

Yes, while the chomp better than the no chomp, it is not perfect. If the string is something like "asadf\r\n" and the OS is \r\n orriented, the chomp gives us "<p>asdf</p>" instead of "<p>asdf</p><p></p>". If we are processing the string on a \n orriented OS, We are out of luck...

If I understand  perldoc perlre the "/s" or "!s" at the end of the regular expression means "Treat string as single line. "

However, in tadman's node, I'm not getting how s/\r\n//s ( or s!\r\n!!s ) means "take off the \r\n at the end of the string" ???



email: mandog

tadman said:

   $fix =~ s!\r\n$!!s;
[download]

Notice the '$' mark in the line: it anchors the '\r\n' to the end of string. Meaning, replace \r\n only if it appears as the last thing in the string.

$i = $i + 1;
$i++;

$i = $i + $i;
$i *= 2;
[download]

I'm not completely satisfied with either -- it's not clear why "\r\n" is used instead of $/, though Ovid's has a distinct advantage of the <p>$_</p> construct.

sub Ovid_Clear_MakePtag2{
  my $fixme = shift;           # take in our parameters
  return join "",              # join with nothing
    map  { "<p>$_</p>" }       # wrap each line in <p></p> tags
    split "\r\n", $fixme;      # break apart on the newlines
}
[download]

sub Abstract_Clear_MakePtag{
  my $fixme = shift;           # take in our parameters
  return "<p>" . 
         join("</p><p>", split "\r\n", $fixme) . 
         "</p>"  
}
[download]

Would this make a good "clear" example?

As for my opinion, I'd go with your example being the clearer of the 3 examples so far.

For me it's simply because it can be read top-down (instead of bottom-up). I despise having to visually scan down several lines for the semicolon, and scan back up to see what's being done. With all of the comments, yours is far more readable to me. Remove the comments, and his becomes much better. One grouping, one explanation.

Ovid's would be re-written as:

sub Readable_Ovid_Clear_MakePtag{
  my $fixme = shift;
  # make newline-breaks into HTML paragraphs
  return join "\r\n",  map { "<p>$_</p>" }
            grep { /\S/ } split "\r\n", $fixme;
}
[download]

If you've done any Lisp (or other functional style programming) you kinda get used to parsing things inside out. You almost could wrap parens around Ovid's version and . . . :)

my $str = "Line 1 has text, but next is an empty line:\r\n\r\nThird li
+ne has text\r\n";

print "Original String:\n'$str'\n\n";
print "Ovid:\n", Ovid_Clear_MakePtag($str), "\n\n";
print "mandog:\n", MakePtag($str), "\n";

sub Ovid_Clear_MakePtag{
  my $fixme = shift;           # take in our parameters
  return join "\r\n",          # join with newlines
    map  { "<p>$_</p>" }       # wrap each line in <p></p> tags
    grep { /\S/ }              # must have at least one non-whitespace
+ character
    split "\r\n", $fixme;      # break apart on the newlines
}

sub MakePtag{
  chomp(my $fixme = shift);    # take in our parameters
  $fixme=~s|(\r\n)|</p><p>|g;  # replace all \r\n with <\p><p>
  $fixme = "<p>$fixme</p>";    # Add beginning and ending tags
  return $fixme;
}
[download]

Original String:
'Line 1 has text, but next is an empty line:

Third line has text
'

Ovid:
<p>Line 1 has text, but next is an empty line:</p>
<p>Third line has text</p>

mandog:
</p>ine 1 has text, but next is an empty line:</p><p></p><p>Third line
+ has text
[download]

--Jim

There is something to keep in mind when talking about "clean" code. Code that operates within a languages strengths in usually more robust, but also more "natural". Sure, you use a regular expression, but Perl isn't really about regular expressions (entirely). Perl is more generally about list processing.

Consider the Schwartzian Transform. This is a powerful took which is the direct product of list oriented thinking. Ovid's solution stems from Perlish thinking. map and grep are list tools, and Ovid combines them into something that is clearly in the languages idiom, and therefore "clean". An anology would be the sentence "Sarcasm is the lowest form of wit I think not".It is grammatically correct, and uses few grammatical concepts. But it is hard to read and understand because it is outside of the languages idiom.

sub YetAnotherMakePtag {
  my $fixme = shift;
  my @lines = split "\r\n", $fixme;
  my @nonblank_lines = grep { /\S/ } @lines;
  my @wrapped_lines = map { "<p>$_</p>" } @nonblank_lines;
  return join("\r\n", @wrapped_lines;
}
[download]

I try to avoid that construct in my code. For example, I always do print "$_\n" foreach (@list) instead of print join("\n", @list), "\n" simply because the first is a more natural translation the actions I wish to perform. (It also reduces repetition of the terminator, and is much more open to modification if you want to do something a little different: print "-->$_<--\n" foreach...).

On the other hand, for pedalogical purposes I think Ovid's is best. It answers your question, it gives a more complete solution, and it introduces a useful technique (chaining) that doesn't particularly obscure the clarity of the example because it's so easy to see the transformation I did above.