[oak perl] Oakland.pm Meeting - Tuesday

[Belden Lyman]

B.E.G wrote:

> I'll be late to today's meeting, but if you want to take a look
> at what I have for the regexp avoidance thing, try this page:
> 
> http://www.panix.com/~eli/perl/noregexp.html

I won't be able to come to tonight's meeting, so thanks for the link.

Two observations:

First: You use the phrase "avoiding regular expressions" to mean two
different things. This is confusing.

In the first sense, you show an example of replacing a regexy parser
with an indexy parser. You indicate that the newer code loops far
fewer times- implying a gain in efficiency (which I don't doubt since
I've seen similar improvements myself when refactoring code).

"Aha", I think to myself. "`Avoiding regular expressions` means
`not using regular expressions`."

In the second sense, you show a delimited text example. Rather than
using a regex attributed to Friedl, you suggest using Text::ParseWords.
But Text::ParseWords uses regular expressions underneath. So does
Text::Balanced.

"Aha", I think to myself. "`Avoiding regular expressions` means
`not writing regular expressions- getting them from somewhere else
for free`."

So... what do you mean by `Avoiding regular expressions`? And to what
end- efficiency, as in the first case? Maintainability, as in the
second case?

====

Second observation :)

	"Note also that the balanced parentheses requirement here (for
	function calls as arguments) means regexps cannot do this."

Regular expressions can do this. perlre.pod shows how to use the
experimental C<(??{ code })> feature + C<qr()> to match nested parens;
``perldoc perlre'' to see how this works.

If I were explaining this to someone, I'd probably say, "Yes, regular
expressions can do this, but the trick to making them do so relies on an
experimental feature which isn't guaranteed to exist in past or future
versions of Perl; sometimes this is a concern for people [but for me it
is no longer as big a concern as it once was]. Plus the trick is just
that: a trick, which means that whoever needs to maintain your code
needs to either know the trick or figure it out- do you want to do that
to whoever comes looking at your code next (possibly you in 3 months!)?
The easier way to do this is to use Text::Balanced or Text::ParseWords-
it's easier on you when writing the code, it's easier on whoever needs
to read it, and it's easier to maintain."

Anyway, I assume you didn't know about this, otherwise you probably
would have written something like the above instead of "regexps cannot
do this"?

====

FWIW, the reliance on an experimental feature C<(??{ code })> to match
nested parens is not why I would eschew the trick mentioned above.
Though functional, I think it's unmaintainable- so I'd use either T::P
or T::B.

Avoiding experimental features simply because they may be removed in the
future can hamper one's ability as a programmer to get the job done.

> 
> There are probably typos in that, if you see any, feel free to
> write back with them. 

See, I took that as a blank check to write back with whatever ramblings
happened to pass through my mind. :)

$0.01
Belden