Only problem's now going to be when all-of-the-sudden their latent source-code compile-time bugs now kill you!

This is nonsense because first, not only are the pragmas lexical, they're already enabled inside the module, so this has no effect whatsoever on the module's code, and second, the user is asking for this module to be imported (it just needs to be documented).

I dunno, I found it very easy to understand what the Anonymonk meant. Is it up to a module author to blow up a script that its consumer may have written dangerously? For whatever reason, some people (ill-advisedly) write code without strict, and it works. If that code loads the OP's module, it will cease to work. That seems simple.

$ cat MyClass.pm
[download]

use strict;
use warnings;

package MyClass {
    use parent 'Exporter';
    our @EXPORT = 'foo';

    sub foo { 42 }
};

1;
[download]




$ cat script.pl
[download]

use lib '.';
use MyClass;

$bar = foo;

print "$bar\n";
[download]




$ perl script.pl
[download]

42
[download]




$ cat MyClass2.pm
[download]

use strict;
use warnings;

package MyClass2 {
    use parent 'Exporter';
    our @EXPORT = 'foo';

    use Import::Into;
    strict->import::into(1);

    sub foo { 42 }
};

1;
[download]




$ cat script2.pl
[download]

use lib '.';
use MyClass2;

$bar = foo;

print "$bar\n";
[download]




$ perl script2.pl
[download]

Global symbol "$bar" requires explicit package name (did you forget to
+ declare "my $bar"?) at script2.pl line 4.
Global symbol "$bar" requires explicit package name (did you forget to
+ declare "my $bar"?) at script2.pl line 6.
Execution of script2.pl aborted due to compilation errors.
[download]

Hope this helps!



The way forward always starts with a minimal test.

I dunno, I found it very easy to understand what the Anonymonk meant. Is it up to a module author to blow up a script that its consumer may have written dangerously? For whatever reason, some people (ill-advisedly) write code without strict, and it works. If that code loads the OP's module, it will cease to work. That seems simple.

I'm reading the AM's post in detail for the third time now and I'm sorry, but I think your interpretation is reaching a bit. The AM may have been attempting to make a comment about whether modules should enable strict in the user's code or not - but that's not what the node says, instead, it says "[the user's] latent source-code compile-time bugs now kill [the module]", which of course is nonsense, and that makes it impossible to tell whether this is miscommunicated, misinformed, or trolling. (Considering the discussion that broke out over it, if it's the latter, they were successful.)

My own opinion on the matter is simple, everyone is free to write their code however they like, whether their choices are to their disadvantage or (hopefully) advantage, and a module author is free to enable strict in the user's code (assuming they document it), and the user is free to use or not use the module or, if they disagree or are forced to work without strict e.g. because they're on a legacy codebase, they can write no strict after loading the module.

Completely agree. Importing strict into somebody else's code is rather presumptuous. Sure, certain packages do it, but they are rather lower-level than this utility.

Sure, certain packages do it, but they are rather lower-level than this utility.

Moo, Role::Tiny, Moose, Mojolicious, Dancer, Dancer2, Test::Most, and lots more...

Yes, that's exactly my point. All of those are frameworks on which you build an app, so it's appropriate to have them export things like strict into the caller's namespace. The OP's utility does not fit that category.



The way forward always starts with a minimal test.

I'd say that importing strict into your caller's scope is acceptable if the package in question defines the way you write your code anyway, like the examples given by haukex do, but presumptuous in an ordinary OO package. But maybe that's what you mean with "lower-level".

Precisely.



The way forward always starts with a minimal test.