in reply to Re: Re: Re: Re: Usage of our
in thread Usage of our

Yes, that's one considered use. If you know C++ or Java, then by using Exporter without restrictions, you may all your variables of your package public; this is usually not good OO programming practice. Using our specifies only which variables you want public, which is the better way to go.

Also, to note: you should have "my $a = ..." in the Exporter example to keep everything strict.


Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Usage of our
by sierrathedog04 (Hermit) on May 21, 2001 at 20:43 UTC
    Actually, what I posted also passes use strict. If you insert 'use strict' into the Exporter example it passes even without using my() on $a.

    I think this is because 'strict' only barfs when there is neither an explicit package statement nor an explicit package identifier nor a lexical scope.

    Thus by explicitly declaring the package as MyPack I no longer need to say $MyPack::a.

      Actually, that is not the case. Try it with a variable name other than $a or $b (which are exempt from explicit package qualification due to their usage in sort routines). Also, using my($a) wouldn't work because lexicals won't be available to the calling program. Lastly, your 'require Exporter' statement is unnecessary because you aren't exporting anything (for that you'd need to also set the @ISA array and one of the EXPORT arrays (or roll your own import() function).

      For further info see: perlman:perlmod and perlman:perlmodlib. You might also want to check out using the h2xs utility to create your module boilerplate.

        Whoops! Just when I thought I was getting past the newbie stage, something like this comes along. As they say in the film This Is Spinal Tap, "it is a fine line between clever and stupid."

        Yes, the Require Exporter statement is superfluous. The code works or breaks the same with or without it.

        Yes, changing the variable name from $a to $aa in the Exporter example breaks the program. (Who would have thought it?)

        And yes, using my() in the package MyPack indeed renders the lexical variable invisible outside of the package. What does work, surprisingly to me, is the following:

        #tempo2.pl use strict; use MyPack; my $myString = $MyPack::aa; print $myString;
        and
        #MyPack.pm package MyPack; use strict; $MyPack::aa = "Read from Mypack"

        Which only goes to show that a global package variable is, well, global—it is visible by default when called using the name of its package.

        The Exporter module, then, must be for some other purpose entirely besides making variables global.

        A few simple concepts: scope, packages. How does it get to be so complicated to us newbies?

        Update: After R(ing)TFM, I realize that Exporter can export the namespace of package variables outside of that package. However, I was not calling it properly; I was not giving it anything to export.