PPC 0032: Optional Strictures and Warnings

[Ovid]

I've created a PPC that combines the ideas from both the stringification module and the GitHub thread about optional strictures.

The PPC proposes a mechanism for adding optional strictures and warnings, using the stringification functionality as the example of an optional stricture.

[Grinnz]

Note there is no "all" flag for strict currently as there is for warnings, so for this example to work, such a flag would also need to be added. But I would suggest a different name (default, standard?), as this proposal is in fact making it not enable all available strictures.

[Ovid]

D'oh! That's what I get for throwing this together too quickly. I've just pushed a new version.

[Grinnz]

I'm not sure whether treating "optional" as a category is the best approach for this. Warnings have a classification separate from their category (see perldiag) which dictates among other things in what cases they are enabled. My thought was to add a classification for optional warnings which could then be added to any category that makes sense. The category approach would make them easier to enable all at once, but I'm not sure that's necessary. Difficult to reason about some of this until we know what optional warnings we will want to add.

[Ovid]

I'm not sure, either. That's why it's listed as open question number 3, with a link to the original discussion.

[leonerd]

There's something of an overlapping of ideas here. This doc is both proposing a general idea for non-default strictness flags or warnings and additionally proposing details about one specific flag for it. I'm not sure if it would make more sense to discuss those two parts separately?

[Grinnz]

Maybe, but the specific features we wish to accomplish with it really assists in the discussion about the general design

[FractalBoy]

Hi, hope it's okay to comment. Just wanted to put in my two cents that this stringification stricture makes more sense to me as a warning. Would it be possible at the very least to make it a warning as well as a stricture? The CPAN module gives that option but I don't see it mentioned here.

For example, I may want to turn it on and then put in some debugging print statements. Having it crash in that scenario if I forget to do no strict 'stringification' for that block would be a little annoying.

Also would this also handle other stringy operations such as eq and eval (the CPAN module mentions that substr and regexes are not yet handled)? Or using the ref as a class name to access class methods? Just to name a few that the CPAN module doesn't mention.

[Grinnz]

Or using the ref as a class name to access class methods?

This is already an error for unblessed references, so explicit stringification would be needed via some other method that would already be handled:

> perl -E'[]->foo'
Can't call method "foo" on unblessed reference at -e line 1.

[FractalBoy]

Oh I meant something like this:

use File::Spec;
my $mod = 'File::Spec';
$mod->catfile(qw(a b));

I guess for a stringified ref it would require explicit stringification, which would already trip the stricture. So nevermind on that one.

my $mod = [];
$mod = "$mod";
$mod->catfile(qw(a b));

Edit: re-reading, that is exactly what you said, my apologies.

[akarelas]

I've been using $hash{$ref} all my life and have found it very useful. How come I'm the only one? Is it bad practice somehow?

[Grinnz]

It's not necessarily bad practice, but it's usually just a "dirty" substitute for using refaddr, and in either case I believe it's not thread-safe as the ref addresses will change on clone.

[akarelas]

Wouldn't having to type refaddr inside every hash index (as in $hash{refaddr $ref}) be tiresome and more error-prone? (what if I forget for example to type refaddr once?)

[haarg]

Sometimes correct code is longer than incorrect code. If there were warnings or errors on stringification of refs, forgetting to use refaddr would be immediately noticeable.

[akarelas]

Indeed. But is it really dirty to use a ref as a hash key? Could you please explain why or give an example?

[akarelas]

Ok, i guess I can restrict this practice in certain modules only, which will contain no strict 'strings'; when it eventually gets turned on by default.

[guest20]

stringification feels more like a fatal warning than a stricture. It has the vibe of a fatal "hey, you stringified an undef" more than an undeclared variable / sub.