in reply to Re: Why do I get a "used only once" warning here?
in thread Why do I get a "used only once" warning here?

Indeed, the way you wrote it, it would work. In my original design, the variable would be in a different package, so neither

use vars qw(%MyApp::once);
nor
our %MyApp::once;
would have worked, because package qualifications are not allowed in use vars and our; put actually I don't need to put once in its own package; I can simply have it in my current package, and this would make your solution indeed feasible.

-- 
Ronald Fischer <ynnor@mm.st>

Replies are listed 'Best First'.
Re^3: Why do I get a "used only once" warning here?
by AnomalousMonk (Archbishop) on Mar 16, 2009 at 19:11 UTC
    ... the variable would be in a different package ...
    ... I don't need to put  once in its own package; I can simply have it in my current package, and this would make your solution indeed feasible.
    I'm still a bit confused, and I suspect we may be posting at cross-purposes.

    What I wanted to illustrate is that a package variable may be declared in any package at any time (with either use vars or our), and may then be accessed from any other package at any (executionally subsequent) time.

    >perl -wMstrict -le "package Some::Package; our $scalar = 'foo'; package Some::Other::Package; print $Some::Package::scalar; print 'current package is ', eval { scalar caller }; " foo current package is Some::Other::Package
    Update: Oops... Forgot to include example code.
      What I wanted to illustrate is that a package variable may be declared in any package at any time (with either use vars or our), and may then be accessed from any other package at any (executionally subsequent) time.

      I see. I had misunderstood you here. So I would declare it for instance in the logging package. Makes sense.

      -- 
      Ronald Fischer <ynnor@mm.st>
        So I would declare it for instance in the logging package.
        Exactly. Or, you could declare it in a package of your own definition as you seem to have originally intended. The latter course avoids the possibility that a 'reasonable' name given by you to your variable might at some later time be used by the maintainer of the logging module you're using, thus engendering a naming collision with effects that might suddenly appear from the blue and be rather puzzling and difficult to debug.

        Or, you could make your new package inherit from the logging module you're using, extending the attributes and functions of the old module... but that's a whole 'nother discussion!