So, I can not use local with use strict?

I just gave two examples that use local and strict.

I don't feel safe to use because there is no scope for it.

Local only works on package (global) variables. You can't use local on lexical (scoped) variables.

(Well, it also works hash elements and array elements, but I don't see how that could be useful here.)

Is it safe to use our with threads?

In Perl threads, each thread has its own variables unless you share them explicitly. This applies to both lexical (scoped) and package (global) variables.

Strict makes you declare your variables. Local does not declare a variable...
it makes a backup copy of an existing global variable, and that global is still global.

my declares a local variable. my is what you want to use.

Strict makes you declare your variables.

Wrong.

Strict only prevents unqualified variables to default to package variables, by throwing an exception. Declaring a variable with my is only one of the ways to satisfy strict. But you may introduce a variable using local, our or use vars. Or use a fully qualified name.

> But you may introduce a variable using local,

no you can't, local doesn't declare!

lanx@nc10-ubuntu:~$ perl -e 'use strict; local $x=4; print $x'
Global symbol "$x" requires explicit package name at -e line 1.
Global symbol "$x" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.
lanx@nc10-ubuntu:~$ perl -e 'use strict; our $x=4; print $x'
4lanx@nc10-ubuntu:~$
[download]

Cheers Rolf

I think you should first make up your mind what kind of variables you would like to have. We should not use the term "local variable" in Perl, since it is not clear what this means. Perl has two type of variables: Lexical variables, and package global variables. Which one would you like to use?

Lexical variables are declared using my or state - the latter only if you are using Perl 5.10, and if feature 'state' is enabled.

Package global variables do not need to be declared. They can be declared using our. If you decide not to declare them, and have strict in effect (which is for sure a good idea), you have to qualify them with the full package name.

local is a function which operates on package global variables. Hence if you use it, and have strict in effect, you need to qualify the variable name with the package.

My impression is that a lot of the confusion about your posting arose, because you did not explain in the first place what kind of variable you want to use, so some people thought you are interested in lexicals (and suggested to use my), while others thought you want to have package globals (and suggested to use our).

If possible I would like to use variable that is accessible bye ref_test2 without passing in as argument.

sub ref_test1
{
    local our $type="connect";
    print "Here in ref_test1.\n";
    ref_test2();
}

sub ref_test2
{
    our $type;
    print "Type: $type\n";
    print "Here in ref_test2\n";
}
[download]

If possible I would like to use variable that is accessible bye ref_test2 without passing in as argument.

So you mean you want to share a variable between functions? The solution here is to use a lexical within a closure:

{ # closure starts here
  my $shared_variable;
  sub ref_test1 { ... }
  sub ref_test2 { ... }
}
[download]

-- 
Ronald Fischer <ynnor@mm.st>

We should not use the term "local variable" in Perl, since it is not clear what this means. Perl has two type of variables: Lexical variables, and package global variables.

If the goal is to remain clear, talk about "lexical variables" (or lexically scoped variables) vs. "package variables". Don't go pretending that only package variables can be global.

So, I can not use local with use strict?

The problem is the extension of the scope. You do local $var in a certain scope. But the other use is in a different scope. That is the cause of the error. Replacing the local with my doesn't solve that.

Note that anyone with a reply suggesting you replace the 'local' with 'my' doesn't understand why you are getting the error.

I did just that, and I beg to differ. The solution I recommended uses my and works quite well. While changing to my alone is not enough, it can definitely be part of the solution.

I beg to differ. The solution I recommended uses my and works quite well. While changing to my alone is not enough..

You're doing it again.