japhy, I like what this does, but it strikes me as similar to the English module: a nice idea that few, if any, use. However, it might be justifiable the way CGI.pm's HTML methods are: as a way of validating the syntax of the output.

For example, many people object to the following in a CGI program:

print $q->Tr(  { -bgcolor => $bgcolor[ $toggle->() ] },
               $q->td( $key . "  " ),
               $q->td( $q->pre( $data ) );
[download]

Why don't I just use HTML with a here document or a template? In this case, the value of the CGI.pm HTML functions is apparent:

• I can't mis-nest tags.
• I can't forget to close a tag.
• I get a handy "syntax check" of HTML code that ordinarily wouldn't be checked.

The last item isn't as much of an issue here, but the first two could be. I think that if it's constructed properly, invalid constructs may be more glaring and/or harder to construct. For example, how many times have we seen regexes like the following?

$somevar =~ /^[\d|\w|\*]+$/; # Bad regex, no biscuit.
[download]

With your syntax, a person could more naturally write the following:

$match_stuff = form_REx(
  start,          # ^
  class("\d\w*"), # [\d|\w|\*] <- still bad!
    one_or_more,  # +
  end             # $
);
[download]

And you could output /^[\w*]+$/ for the regex (assuming that you check for existence of overlapping metacharacters). This would help with regex syntax problems and could cut down on some of the more insidious logic problems that newbies (and Ovid) are prone to.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.