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
In reply to Re^2: Is Text::Balanced production ready?
by Jeffrey Kegler
in thread Is Text::Balanced production ready?
by Jeffrey Kegler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |