Is Text::Balanced production ready?

[Jeffrey Kegler]

The question in my title seems a strange one to ask about a Perl CORE module, but in node 486756, Damian himself classes it as one of the "Special-purpose Damian modules that are useful for developing other modules or for solving difficult implementation problems, but which probably shouldn't be used directly in application code". In other words, no, not production ready.

However, node 486756 is dated Aug 25, 2005, and on 19 Dec 2006, Text-Balanced-v2.0.0 was released, clearly labeled as a major release. I could assume that Text::Balanced is production ready, but I wonder if any monks can confirm that Text::Balanced has evolved beyond the "not directly in production code" stage.

By the way, no slight against Damian is intended in asking the question. Text::Balanced targets a problem where the first 10% of the effort solves 90% of the problem, and the last 50% of the effort is needed to deal with the remaining .01%. A module developer could quite reasonably decide the law of diminishing returns had taken over and that perfection, if attainable, was not worth the effort.

thanks, jeffrey kegler

[shmem]

Special-purpose Damian modules that are useful for developing other modules or for solving difficult implementation problems, but which probably shouldn't be used directly in application code

That categorization looks rather odd to me. In what sense is a module you shouldn't use in production code good for "developing other modules"? Reading the code and getting inspired on how (not) to do things? Reading the code and understanding every bit and using those parts you absolutely can assert as being safe? Using that module in other modules you use in production code, thus using them indirectly?

TheDamian has given a hint in the BUGS section of that particular module:

There are undoubtedly serious bugs lurking somewhere in this code, if only because parts of it give the impression of understanding a great deal more about Perl than they really do.

OTOH many of the modules in that list are used heavily in production code (in the sense of CPAN modules being battle-tested, as dragonchild would have it :-) - Lingua::EN::Inflect comes to mind, Catalyst makes heavy use of Attribute::Handlers and NEXT, Hook::LexWrap is often recommended and so on. So, these modules might already be "battle tested" despite of any disclaimer they contain.

The general rules hold - don't use things you don't understand, because doing so leads to cargo cult code; read the docs and read the test suite: if your use cases fall within the boundary set up by those; if the bug list isn't too long and doesn't contain no-nos; if the module isn't alpha (i.e. hasn't too many moving parts), then it probably is production ready.

Of course, it depends on what you are producing and on your own notion of "production ready". What would be your answer?

[Jeffrey Kegler]

That categorization looks rather odd to me. In what sense is a module you shouldn't use in production code good for "developing other modules"?

My understanding of what Damian means here, includes things like use in test scripts; use in creating chunks of code that will be incorporated in production code after examination and testing; use in pretty-printers and checking for best practices; use for automatically rewriting all your array accesses to hash accesses; use in examining test results; etc. This "indirect" realm is surprisingly large, and Perl has inhabited it for years. I've been using Perl since 1987 (Perl 1), and acceptance that anything in Perl could be called "production quality" was non-existent to minimal in the beginning. It was a long time before a client would take a deliverable in Perl, as opposed to a deliverable created using Perl. Perl has a long history in this "indirect" demimonde.

On the other point, one way of answering the question of "Is it production ready?" is to ask: "Suppose the time were available for you to write this in C or C++, as opposed to Perl using the Text::Balanced module? Would you think the result posed more risks, as many, or fewer?"

thanks, jeffrey kegler

[samtregar]

I've used it in plenty of production code (HTML::Template::Expr comes to mind). Beware though, it can be amazingly slow. Just don't use it in any performance-sensitive code and you should be fine.

-sam

[renodino]

What are you trying to do with it ? I've used it for a source filter (SQL::Preproc) with only one issue I needed to work around (heredocs, which I believe has since been fixed). That said, unless you're parsing Perl code, I'd suggest trying to exersize your regex muscles first.

[Jeffrey Kegler]

What are you trying to do with it ?

I'm designing a parser specification which includes Perl callbacks. There are good examples of this in both Parse::RecDescent and Parse::Yapp. Damian, of course, uses his own Text::Balanced in Parse::RecDescent.

Francois Desarmenien codes his own much simpler approach in Parse::Yapp. Perl callbacks are contained in brackets. The Perl code may contain nested brackets, and escaped ones are ignored in counting the nesting. Francois knows this is far from dealing with every possibility in legal Perl 5, but he leaves the others up to the user to fix. Francois suggests inserting a comment with balancing brackets into the Perl callback as one solution.

So I have examples before me of the same problem being solved by two excellent programmers in different ways.

[renodino]

Ah, that explains it. Ergo, regexen are not likely to get the job done. In that case, I'd say Text::Balanced is a good bet.

I suppose I should mention PPI as well, it might make it easier to manipulate the Perl pieces. However, if you're just trying to scan over/capture the Perl pieces, then T::B should be fine.