[oak perl] Oakland.pm Meeting - Tuesday

George Woolley george at metaart.org
Tue Feb 10 17:59:51 CST 2004


Belden,
One of the reasons I was glad Elijah provided the URL
was because I was hoping you'd get a chance to see
what he wrote.
I was even hoping you'd comment.

However, it hadn't occurred to me you'd be so quick.
Now, we'll talk about your comments at the meeting too.
Thanks!
George

On Tuesday 10 February 2004 3:06 pm, Belden Lyman wrote:
> 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
>
> _______________________________________________
> Oakland mailing list
> Oakland at mail.pm.org
> http://mail.pm.org/mailman/listinfo/oakland




More information about the Oakland mailing list