As the current maintainer of Text::Balanced,
And *thank-you* for taking on that role, David! :-)
(2) extract_multiple will recognize only the empty list and (undef, ...) return values from extractor functions as match failures. This is what the POD currently states, but ('', ...) was previously also recognized as a match failure in the actual code. Under the new proposal, ('', ...) is not returned by any built-in extractor either on success or failure, so it usually will make no difference. Custom extractors will be allowed to return ('', ...) on success in the trivial case even though I don't see much practical application for that.
Actually, there's an important one -- "deleting" extracted parts. That is, accepting "" as a valid match will allow us to create custom extractors that effectively throw away the data they've successfully extracted. That's handy for dealing with comments, for example.
I would have prefered the return value on failure in list context to be the empty list (like the private _match_* functions) since that would permit code like
elsif ($grammar =~ m/(?=$ACTION)/gco and do { ($code) = extract_codeblock($grammar); $code })
in Parse::RecDescent to be rewritten as
elsif ($grammar =~ m/(?=$ACTION)/gco and ($code) = extract_codeblock($grammar))
but some code actually does rely on the $$textref in (undef, $$textref, undef) being there. Perhaps a 'use' option code be given to enable this behavior.
Returning the "remainder" text supports the "extract-and-remove" metaphor:
($extracted, $remainder, $pre) = extract_whatever($remainder, @opts);
which, if we just returned empty list would have to be:
($extracted, undef, $pre) = extract_whatever($remainder, @opts);
substr($remainder, 0, pos $remainder-1) = "";which I felt was rather a high price to pay.
I would be fine with a C<use> option to toggle the behaviour though.
Damian
