Splitting this one out since it seems a bit bigger in scope:
On Wed, 26 Jan 2022 at 07:54, Scott Baker <scott@perturb.org> wrote:
>
> 1. It would be great if the strings were Globally unique so they were
> easily searchable in Google. I know we’re all old Perl programmers and are
> really comfortable with perldoc but the novice Perl programmer is
> going to hit Google first. If the codes were something like Perl-Q1793
> or Perl_W18 then a Google search will always turn up the right
> documentation.
>
> I imagine there will be a lot of work to implement this, as we'd have to
> go back through all the common warnings/errors. We could do them slowly
> over time, we're not forced to do them all en masse in one release.
>
The basic idea behind "copy, paste, get sensible results" when looking
these things up seems laudable enough to me (whether online, perldoc,
talking to people about it). There are a few parts to this, but combined
with Paul's question about "what warnings category do we use for
discouraged @_ in signature-using subs"... maybe it's worth considering
core warnings and errors in a wider context?
Could we move over to a common object-based format, for example - one that
provides message, diagnostic information, error codes, categories and/or
tags? How would other error information, such as $!, fit into that? Are
there reasons _not_ to consider that - performance and memory usage, for
example, or simply "here are some things that would break"?
So yes, requirements like "make it easy to look up errors and warnings if
you're not familiar with Perl" are a good start, just seems like an
opportunity to start working on something a bit more extensible - and
future-proof! - than our current plain-strings-only model.
Plus I'm not even sure if we _can_ reliably assume "strings", this ties in
to the bytestring vs. "Unicode"-string discussions: as an example, if
there's a filename in the mix, is that going to be dumping raw UTF-8 bytes
in there? Should all warning+error messages be decoded from UTF-8 before
any further processing such as string matching or passing to output layers?
If so... is anyone actually doing that?
$ perl -e'
use utf8;
BEGIN {
binmode STDERR, ":encoding(UTF-8)";
warn "UTF-8 output layer on: Acme::?_?;";
}
use Acme::?_?;'
UTF-8 output layer on: Acme::?_?; at -e line 5.
Can't locate Acme/ಠ_ಠ.pm in @INC
^ if someone were to call that behaviour inconsistent, I would not exactly
rush to disagree!
>
On Wed, 26 Jan 2022 at 07:54, Scott Baker <scott@perturb.org> wrote:
>
> 1. It would be great if the strings were Globally unique so they were
> easily searchable in Google. I know we’re all old Perl programmers and are
> really comfortable with perldoc but the novice Perl programmer is
> going to hit Google first. If the codes were something like Perl-Q1793
> or Perl_W18 then a Google search will always turn up the right
> documentation.
>
> I imagine there will be a lot of work to implement this, as we'd have to
> go back through all the common warnings/errors. We could do them slowly
> over time, we're not forced to do them all en masse in one release.
>
The basic idea behind "copy, paste, get sensible results" when looking
these things up seems laudable enough to me (whether online, perldoc,
talking to people about it). There are a few parts to this, but combined
with Paul's question about "what warnings category do we use for
discouraged @_ in signature-using subs"... maybe it's worth considering
core warnings and errors in a wider context?
Could we move over to a common object-based format, for example - one that
provides message, diagnostic information, error codes, categories and/or
tags? How would other error information, such as $!, fit into that? Are
there reasons _not_ to consider that - performance and memory usage, for
example, or simply "here are some things that would break"?
So yes, requirements like "make it easy to look up errors and warnings if
you're not familiar with Perl" are a good start, just seems like an
opportunity to start working on something a bit more extensible - and
future-proof! - than our current plain-strings-only model.
Plus I'm not even sure if we _can_ reliably assume "strings", this ties in
to the bytestring vs. "Unicode"-string discussions: as an example, if
there's a filename in the mix, is that going to be dumping raw UTF-8 bytes
in there? Should all warning+error messages be decoded from UTF-8 before
any further processing such as string matching or passing to output layers?
If so... is anyone actually doing that?
$ perl -e'
use utf8;
BEGIN {
binmode STDERR, ":encoding(UTF-8)";
warn "UTF-8 output layer on: Acme::?_?;";
}
use Acme::?_?;'
UTF-8 output layer on: Acme::?_?; at -e line 5.
Can't locate Acme/ಠ_ಠ.pm in @INC
^ if someone were to call that behaviour inconsistent, I would not exactly
rush to disagree!
>