in reply to Triggering 'strict' from within a package

I rolled my own importer which automatically places the modules in main::

Ah, you mean the package main; importer code :-)

Anyway, strict is a lexical pragma, so you cannot set at it for other files. I assume this was done to keep non-strict code working together with strict code.

this is also one of the reasons you have to use strict; for every module you use instead of defining it in the top-level code.

Update: I cannot think of any reason to turn off strict based on the location of the script, so I would suggest keeping it on where it makes sense.

Hope this explains a bit,
Joost.

-- Joost downtime n. The period during which a system is error-free and immune from user input.

Replies are listed 'Best First'.
Re: Re: Triggering 'strict' from within a package
by kal (Hermit) on Aug 12, 2002 at 15:14 UTC
    Ah, you mean the package main; importer code :-)

    Sadly not :) It will actually look at other stuff - such as @INC ordering - based on location (& other factors) also, so it will actually load different version of a module based on what environment the script is being run in.

    Anyway, strict is a lexical pragma, so you cannot set at it for other files. I assume this was done to keep non-strict code working together with strict code

    I had a horrible feeling something like that might be the case. Note, though, that it's not a case of turning it off, but more a case of not turning it on - it's just not useful in a lot of cases.

    Cheers!

      Note, though, that it's not a case of turning it off, but more a case of not turning it on - it's just not useful in a lot of cases.
      Describe "a lot of cases" where "it's just not useful". Either you're badly informed, or I am.

      (I can see the gallery taking side bets. {grin})

      -- Randal L. Schwartz, Perl hacker

        Either you're badly informed, or I am.

        This is what is known as an argument you can't win, I believe ;)

        Basically, as I said further down, we try to keep the Apache logs free for traffic analysis, which means diverting errors elsewhere. Also, we do have a lot of scripts which are either 'trivial' (small, or we don't care if they fall over) or 'old' - either of which aren't suitable for 'strict' (at least, not in my opinion). Since this package of mine is going to be global (I want all our scripts using it really), it's not really suitable to set strictness policy within it - it's a per-script thing.

        However, on a development server, it's not optional :-).