PPCs
PPCs copied to clipboard
Perl
PPC 0032: Optional Strictures and Warnings
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.
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?
Maybe, but the specific features we wish to accomplish with it really assists in the discussion about the general design
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.
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.
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?
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.
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?)
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.
Indeed. But is it really dirty to use a ref as a hash key? Could you please explain why or give an example?
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.
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.
