Front page | perl.perl5.porters |
Postings from June 2022
> On Jun 8, 2022, at 11:51, Dan Book <grinnz@gmail.com> wrote: > > On Wed, Jun 8, 2022 at 8:16 AM Felipe Gasper <felipe@felipegasper.com> wrote: > > > On Jun 7, 2022, at 13:38, Dan Book <grinnz@gmail.com> wrote: > > > > On Tue, Jun 7, 2022 at 12:56 PM Felipe Gasper <felipe@felipegasper.com> wrote: > > > > The idea is simple: apply the familiar pattern of POSIX error names (ENOENT, EPERM, etc.) to Perl. These will be easily searchable in search engines, and we can list them in something like perlhelpcodes.pod. > > > > Thoughts? > > > > I think it's useful but unfortunately it cannot be protected by a feature flag, since the error messages will by their nature escape that scope and cause breakage. > > It seems unlikely that a CPAN/DarkPAN module would enable helpcodes for the same reason as pertains with signatures: the “new hotness” restricts the module’s compatibility without providing much advantage for the module author/maintainer. > > I would think helpcodes mostly useful in “end applications”, where the author can control whether the feature is used or not. > > The end user can't control whether the feature is used when warnings or errors are emitted from modules they use. Because features are lexical. Agreed. Thus, it becomes the module maintainer’s responsibility either: - to forgo use of helpcodes (the likely strategy for CPAN modules), or - to document their use as part of the module’s interface The former seems much more likely for publicly-distributed code since such modules usually prize backward compatibility. The module itself won’t benefit from their use, so there’s no real incentive. Either way, though, I don’t see how it’s problematic. -FGThread Previous | Thread Next