in reply to Re^6: My globals are visable; but undef'ed
in thread My globals are visable; but undef'ed

I think we're more or less on the same frequency here:
If you are using our to access data within one package only, why are you making it a global when you could trivially make it a lexical?
I don't do that, and I didn't mean to imply that I did.

Here are the rules I follow. I use my unless there is a specific reason not to. I will use our for certain standard globals that need to be global, such as @EXPORT_OK. When I need to share variables across multiple files I try to use Exporter to export it from one place to all of the places that need it.
I'm with you so far.
If that solution won't work, then I will "use vars" for the declaration. I never use our for any variables that I've invented within my code. ...
I really don't see why you'd make that distinction. I just use our() for all package variables.

"What should it profit a man, if he should win a flame war, yet lose his cool?"
  • Comment on Re^7: My globals are visable; but undef'ed

Replies are listed 'Best First'.
Re^8: My globals are visable; but undef'ed
by tilly (Archbishop) on Jul 31, 2008 at 22:37 UTC
    If that solution won't work, then I will "use vars" for the declaration. I never use our for any variables that I've invented within my code. ...
    I really don't see why you'd make that distinction. I just use our() for all package variables.
    Because if I have to type a variable name in two different files, my typo rate is fairly high. Therefore I really, really want to declare it in one file, and let strict.pm catch my typos everywhere else.

    The only time I don't do that is when I'm working with an external API that doesn't give me the option. For example if I were to reinvent Exporter I would seriously think about pre-declaring @EXPORT_OK in the caller's space so that the caller can just access it and will get a useful error for accidentally typing @EXPROT_OK. Were I reinventing it for my own use, then I would definitely do that.

    Let me think about it and see if there is any situation where I would use our in my own code. Hmmm.

    There is one. And that is for a situation where I want a variable that I only access in one file but I want to use local on it. I'm not sure when that need might come up since it has never yet happened. Of course if Larry would allow local to be used on lexical variables, than that need would go away. (Note, he disallows it because of the potential for confusion, and not for technical difficulty. You can use local in more places than you might think - I like using it on the values of lexically scoped hashes.)

[reply]
      Because if I have to type a variable name in two different files, my typo rate is fairly high. Therefore I really, really want to declare it in one file, and let strict.pm catch my typos everywhere else.
      But putting use vars($var) does not make any difference from putting our $var; at the top of the file for this, or as far as I know any other use. In other words, I just use our as a direct replacement for vars. And if you do, there really isn't any difference (except that vars has more awkward scope).

      And I don't use attributes on global variables (I do use them on global subroutines, though).

      update: or are you really adding to the same package from different files as much as that? I really do that once or twice a year.

      "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]
[d/l]
[select]
        Yes, it does make a difference. If I have use vars qw($var); in one library, and I use that library in my script, then $var is declared in my script as well. Which means that if I get to my script and think it should be $vars, that thinko is caught by strict.pm.

        If I was using our instead then that mistake would never be caught because I would have declared it differently in the library and the script.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom