So, I can use $p::var as some arbitrary global variable even under "use strict" and even when "p" is not referring to any package at all?

In that example, "p" is is referring to a package. It doesn't matter that you didn't enter the package namespace anywhere with pacakge p; first though. Yes, you can use it even under use strict; because it is fully qualified. Even strict checking assumes that you know what you are doing when you fully qualify a variable name.

Is it an advisable thing to do?

Use global variables from random packages? No. And it is probably better to predeclare globals with use vars (or our which isn't exactly the same thing) than to not declare and use fully qualified names.

-sauoq
"My two cents aren't worth a dime.";

There are rarely any hard or fast rules, but generally, variables should have as restricted a scope as is feasible. If other packages don't need your variable, don't make it a package variable. If they do need it, write subs that can set and fetch the variable (if something else changes the variable when you didn't expect it, you can then easily insert debugging code to find out what is changing it. That's tougher to do with package variables).

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)

Well, first, $p::var isn't a global variable; it's a package variable. And p:: does refer to a package; it specifically refers to the package p. So I would reformat your question as follows:

And the answer is, yes. I suppose you could consider that a deficiency of "use strict".

Well, personally I would say not. It's bound to confuse someone somewhere. And technically it's allowing you to autovivify a variable, which is what you're trying to avoid by use'ing strict. So I'd avoid it.

Well, first, $p::var isn't a global variable; it's a package variable.

Since all package variables are global it is not uncommon to refer to them as global variables.

So, I can use $p::var as some arbitrary package variable even under "use strict" and even when "p" doesn't refer to a package that I've specifically declared (i.e., with the "package" keyword)?

And the answer is, yes. I suppose you could consider that a deficiency of "use strict".

The problem here is that the package keyword is not declarative at all (nor does it define the beginning or ending of a lexical scope). It is more "informative" than anything else. All it says is that within the lexical scope involved unqualified identifiers are to be considered to be in a particular package namespace. In fact there is no means of declaring a package or global variable in perl (before you disagree consider that our and use vars are no more declarative than a package statement). Interestingly there are a few variables that can _only_ be reached through a fully qualified package name.

Also, I dont really think that you can consider this a deficiency of "use strict", if anything its a feature. After all, there are occasions where you may want to reach into a package that doesnt really exist yet... Hopefully they dont occur often, but when you need to do something like this it sure is nice that you can. IMO the benefits outweigh the hassle of tracking down typos in fully qualified names.

Well, personally I would say not. It's bound to confuse someone somewhere. And technically it's allowing you to autovivify a variable, which is what you're trying to avoid by use'ing strict. So I'd avoid it.

This is an interesting point of view. 'use strict' isnt to prevent the autovivification of variables (although it does that as a side effect), its to prevent perl from thinking you meant some arbitrary package variable when you made a typo. Consider that the variable can already be "vivified" (in your terms ;-) but strict will still complain:

use strict;
$foo::bar=1;
package foo;
$bar=1;
[download]

While I suppose there is some sense in thinking of globals/dynamics/package vars (pick your term) as being created, but I personally don't. To me all packages exists simultaneously, as do all package vars. The fact that they havent been thought of or used yet is irelevent. :-)


---
demerphq

_{<Elian> And I do take a kind of perverse pleasure in having an OO assembly language...}