Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Exporting use strict/warnings into main::

by Anonymous Monk
on May 18, 2020 at 20:15 UTC ( #11116915=note: print w/replies, xml ) Need Help??


in reply to Exporting use strict/warnings into main::

Only problem's now going to be when all-of-the-sudden their latent source-code compile-time bugs now kill you!
  • Comment on Re: Exporting use strict/warnings into main::

Replies are listed 'Best First'.
Re^2: Exporting use strict/warnings into main::
by haukex (Bishop) on May 19, 2020 at 06:47 UTC
    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
      use strict; use warnings; package MyClass { use parent 'Exporter'; our @EXPORT = 'foo'; sub foo { 42 } }; 1;

      $ cat script.pl
      use lib '.'; use MyClass; $bar = foo; print "$bar\n";

      $ perl script.pl
      42

      $ cat MyClass2.pm
      use strict; use warnings; package MyClass2 { use parent 'Exporter'; our @EXPORT = 'foo'; use Import::Into; strict->import::into(1); sub foo { 42 } }; 1;

      $ cat script2.pl
      use lib '.'; use MyClass2; $bar = foo; print "$bar\n";

      $ perl script2.pl
      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.

      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.

Re^2: Exporting use strict/warnings into main::
by 1nickt (Abbot) on May 18, 2020 at 23:31 UTC

    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.


    The way forward always starts with a minimal test.

        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11116915]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others examining the Monastery: (11)
As of 2020-09-29 14:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    If at first I donít succeed, I Ö










    Results (146 votes). Check out past polls.

    Notices?