my command (sorry newbe question)

[Torch]

I just started a little perl programming. I noticed a lot of "my"
commands before declaring a variable. I was under the impression that
the "my" command was only used to declare a variable locally (like for
instance in a subroutine). I noticed from a code I got that in some
cases "my" was used and in other cases not. Can somebody help me with
understanding when to use "my" and when not to use "my"

 

[Andreas Kahari]

cases "my" was used and in other cases not. Can somebody help me with
understanding when to use "my" and when not to use "my"

Maybe these articles could help you a tiny bit:

http://perl.about.com/library/weekly/aa022101a.htm
http://perl.about.com/library/weekly/aa022801a.htm

 

[Kasp]

Make the following two lines as the first lines of your code and you will
know when to use my or not. Its a very helpful and also a good practice!

use strict;
use warnings;

--

 

[Tad McClellan]

I noticed a lot of "my"
commands before declaring a variable.

my() is not a command.

It is not "before" declaring a variable, my() _is_ the
declaring of the variable.

I was under the impression that
the "my" command was only used to declare a variable locally (like for
instance in a subroutine).

It is used to control scope, whether the scope extends for a block
or for an entire file.

I noticed from a code I got that in some
cases "my" was used and in other cases not. Can somebody help me with
understanding when to use "my" and when not to use "my"

You should always prefer lexical (my) variables over
dynamic (our) variables, except when you can't.


See:

perldoc -q my

What's the difference between dynamic and lexical (static)
scoping? Between local() and my()?

and:

perldoc strict


See also:

"Coping with Scoping":

http://perl.plover.com/FAQs/Namespaces.html

 

[Ben Morrow]

[please don't top-post]

You don't always need the "my" when you declare a variable. However it can
be a good idea if your script calls another script or module in case there
might be another variable with the same name.

You do if you 'use strict', with the exception of the variables listed
in perlvar, and package variables which you declare with 'our'.

You ought to be using strict unless you know a good reason not to.

Ben

 

[Chris Mattern]

You don't always need the "my" when you declare a variable.

If you program with strict (and you should *always* program with
strict), then you will need *something*--my, our, global, whatever...
It should by "my" unless there's a reason for it to be something
else.

However it can
be a good idea if your script calls another script or module in case there
might be another variable with the same name.

Making your variables local when possible is always a good idea.

Chris Mattern

 

[Tad McClellan]

Making your variables local when possible is always a good idea.

Except we can't use the usual meaning of "local" because of its
_un_usual meaning in the Perl world.

In Perl, local() variables are *global* variables!

(it is the variable's _value_ that is "local")


Restricting the scope of variables when possible is always a good idea.

 

[Brad Baxter]

If you program with strict (and you should *always* program with
strict), then you will need *something*--my, our, global, whatever...

my, our, local, PACKAGE::, what else?

Regards,

Brad

 

[Ben Morrow]

my, our, local, PACKAGE::, what else?

use vars

*var = \$var;

These are equivalent, and both have been obsoleted by our().

Ben

 

[Brad Baxter]

use vars

*var = \$var;

These are equivalent, and both have been obsoleted by our().

Yes, I should have included use vars with our. But I don't follow the
second example, so I'm sure I'm missing something that I ought to know.

In the first case below, I took your example literally, though I feel you
didn't mean it that way. In the second case, I changed it to what I
thought you meant. But I don't catch how this would be used to avoid the
other ways to declare ...

bmb >> cat -n ./qt
1 #!/usr/local/bin/perl
2 use strict;
3 use warnings;
4
5 *var = \$var;

bmb >> ./qt
Variable "$var" is not imported at ./qt line 5.
Global symbol "$var" requires explicit package name at ./qt line 5.
Execution of ./qt aborted due to compilation errors.


bmb >> cat -n ./qt
1 #!/usr/local/bin/perl
2 use strict;
3 use warnings;
4 my $var1 = 1;
5 *var2 = \$var1;
6 print $var2;

bmb >> ./qt
Variable "$var2" is not imported at ./qt line 6.
Global symbol "$var2" requires explicit package name at ./qt line 6.
Execution of ./qt aborted due to compilation errors.

Puzzled,

Brad

 

[Ben Morrow]

Yes, I should have included use vars with our.

Well, I wouldn't really say so, given that it's obsolete.

But I don't follow the second example, so I'm sure I'm missing
something that I ought to know.

In the first case below, I took your example literally, though I feel you
didn't mean it that way. In the second case, I changed it to what I
thought you meant. But I don't catch how this would be used to avoid the
other ways to declare ...

Sorry, I was being somewhat facetious and my example was unclear .
Try

perl -Mstrict -e'BEGIN {package vars; *main::var = \$main::var} $var=1'

which is exactly what vars.pm does. Yes, theoretically the BEGIN
block does precisely nothing, but nevertheless it keeps strict happy.

Ben

 

[Brad Baxter]

Well, I wouldn't really say so, given that it's obsolete.

Just that I suspect there's a lot of code folks might see that still uses
it, so it's still good to know about.

Sorry, I was being somewhat facetious and my example was unclear .
Try

perl -Mstrict -e'BEGIN {package vars; *main::var = \$main::var} $var=1'

which is exactly what vars.pm does. Yes, theoretically the BEGIN
block does precisely nothing, but nevertheless it keeps strict happy.

Fair enough, thanks.

Regards,

Brad