Front page | perl.perl5.porters |
Postings from March 2003
That patch also contains changes to diagnostics.pm. These
changes became necessary because the module uses something
akin to "reverse engineering" to obtain its data. Parsing
perldiag.pod to obtain all error message texts and their
explanation is error-prone, mainly because the text on
the =item line must be identical to the format string in the
.c file (not even variations in alphabetic case or spacing
being tolerated) and not all format codes are handled. Also,
it is quite difficult to check that all emitted error
messages are indeed recognized correctly and paired with
the matching explanation. (A wrong explanation for a
diagnostic could be worse than none. ;-)
A better approach would be to
- define macro names, error message format strings and
explaining pod paragraphs in a data file
- generate (say) errmsg.h containing the #defines for
error message format string macros and the =item list
for perldiag.pod from that data file
- change all .c code to refer to macros from errmsg.h
This would guarantee that all error messages would match,
and that error messages occur on perldiag.pod in the correct
sorting order. As an additional advantage, this approach
would permit fairly simple checks whether some error message
is still in use. Also, having all error texts in a single
place would make it easier to enforce a uniform style.
(E.g.: Quoted program snippets are currently shown
surrounded by either "" or '' or `' or nothing. Hex numbers
are preceded by 0x or shown as is.)
Disadavantages:
- Another quirk in the Perl build process
- new dependencies of several .c file on a single .h file
Finally, the modified diagnostics.pm could be made available
to Perl programmers for use in applications, either with or
without the basic Perl messages. The same format for defining
Perl's own error messages would be used for defining a user
program's error messages, to generate "use constant" instead
of define, to produce verbose explanations if so desired.
This may not be all there is to it, and I may have overlooked
something substantial, rendering all of this obsolete. Any
opinions from out there, please?
Regards,
Wolfgang Laun