Ok, you have a point here, but I dont think its relevent.

Fair enough :-) I read your definition of "declare" in your original post to relate to creation. I have obviously misunderstood.

Nothing intrinsic about them "created" anything, instead a rule that is in effect in many situations besides when you use these keywords is responsibile for the autovivification. For instance any fully qualified variable name usage or subroutine declaration would have done the same thing.

True (although there is at least one place where autovivification doesn't happen.)

However, does the fact that you can create symbol tables and symbol table entries in other ways mean that they are not declarations? It seems to fit the definition you gave in your original post:

"They declare that a given object is to be created and henceforth will be reffered to by a given name"

Are packages and package globals not declared in Perl? If we changed Perl so the first occurance of a variable declared it as a lexical in the current scope would that mean that my stopped being a declaration because lexically scoped variables could be created implicitly too?

I'm just trying to figure out what exactly you mean by "declare".

A second issue is that your second example is a poor one. You arent testing for the existance of $Bar there, you are testing for the existance of any variable type with the given name.

I never said I was testing for the existance of $Bar. I said that our "creates a symbol table entry if one doesn't already exist" - and that was exactly what I was testing for :-)

I think to me it comes down to this. Using other approaches I can write a program that is identical from an introspective view to any program written with package and our declarations. However the same is not true with my , or sub (afaik).

I'm not quite sure what you mean by "an introspective view" but I don't see a way to write:

use strict;
use warnings;

sub foo {
    our $Package_global = 'foo';
};

print $Package_global;
[download]

And get an error for the non-explicitly scoped variable in the print without using our.

For me our declares a lexical variable that is automatically aliased to a package global (creating it if it doesn't already exist)... so I think of it as a declaration.

It declares a variable with weird behaviour - but it's still a variable declaration.

I would prefer that there was a better term for what my and sub do, and that "declare" meant the same thing in computereses as it does in english, but alas such is not so. And accordingly I think its dangerous to mix the terms.

Possibly, but (and this may just be me being dim - it's been a long day :-) I'm not seeing how your definition of "declare" excludes our and package.

It it to do with creating things? Is it to do with warnings on scope usage/redefinition? Is it to do with implicit vs explicit creation? Are we talking about declaration of a variable, or the declaration of the thing that the variable refers? Something else?

Update:

I think our is the only way you can apply attributes to package vars too.

our @EXPORT : unique = qw(foo);
[download]

Note: This node is long overdue. I became very busy and distracted right around the time I started this thread, and have either forgotton to follow up or not had the time to respond since then. My apologies for the delay.

However, does the fact that you can create symbol tables and symbol table entries in other ways mean that they are not declarations? It seems to fit the definition you gave in your original post:

"They declare that a given object is to be created and henceforth will be refered to by a given name"

I dont beleive they do fit with this definition. With packages and package variables I think that an explanation such as "requests that the following unqualified identifiers will be considered to be qualified into a specific package and that strict should not consider such variable identifiers to be undeclared lexicals." Also, the ONLY way to get a lexical variable is to use my. I dont need to ever use an our to get a package variable. (Although as you point out I do need to do so if I want attributes on the global.)

I prefer to think that ALL possible global variables and packages exist simultanousely (except they take no resources until mentioned.) This is much akin to the point of view that mathematics is not a medium of creation but rather a medium of discovery. (Mathematical truths exist independantly of whether we know of them or have enumerated them or written them down. They just simply are.) I beleive that this POV avoids all kinds of ugly logical contradicitions if one takes a different view. I will touch on one of these later.

I'm not quite sure what you mean by "an introspective view" but I don't see a way to write: ... And get an error for the non-explicitly scoped variable in the print without using our.

Hmm, depending on the POV I could either say that the empty program is equivelent to this program (both do nothing), or I could say that any uncompilable program is equivelent to this (they dont compile), or I could say that I really meant any program that will run can be written in such a way that neither package nor our is required and have the same results. (Although your point about attributes in the our clause to some degree negates this POV. I think I would still argue that package and our are really compiler pragmata and not declaration.)

For me our declares a lexical variable that is automatically aliased to a package global (creating it if it doesn't already exist)... so I think of it as a declaration.

This makes little sense to me. If its a lexical then how can local affect it? Furthermore there is a way to do exactly what you say here, but doesnt require our:  for my $lexical ($Package::Var) { ... } Now the $lexical is truly an alias.

It declares a variable with weird behaviour - but it's still a variable declaration.

I would say that the behaviour is sufficiently weird that its probably a mistake to use the same terms. I certainly find that its a lot easier to keep things straight by keeping the term declaration strictly limited, and to keep the concept of package and lexical vars strictly seperate.

It it to do with creating things? Is it to do with warnings on scope usage/redefinition? Is it to do with implicit vs explicit creation? Are we talking about declaration of a variable, or the declaration of the thing that the variable refers? Something else?

I believe that resticting "declare" to explicit creation of both the variable name and the underlying object. For instance package Bar; our @foo; indirectly creates the package Bar (if needed), indirectly creates an array if it doesnt exist, indirectly creates a scalar ($package::foo) if it doesnt already exist and tells strict not to consider @foo to be an undeclared lexical, as a well as telling the compiler that any further unqualified identifiers are to be assumed to be qualified to be in the package Foo.

This is whole lot of extra stuff that doesnt happen with a simple my, and I find it difficult and confusing the reconcile the two behaviours under one term. For instance I think its very difficult to consider both our and my to be the same thing (a declaration) when

use strict;
{
  our $foo=10;
}
{
  our $foo;    # same $foo as the other one
  print $foo;
}
[download]

and

use strict;
{
  my $foo=10;
}
{
  my $foo;   # totally different $foo
  print $foo;
}
[download]

Do such different things. At the bare minimum when I use the declaration with regard to our or package(sometimes theres no choice due to a lack of a better term) I always go out of my way to add qualifiers and caveats.

I guess the question here comes down to the sophistication of the programmer involved. A sophisticated perl programmer will understand the finer nuances of the usage of declaration in both contexts and probably wont get confused. A newbie OTOH is going to assume the two behave identically and then is going to be real confused when they experience the apparently contradictory behaviour. To me there is no contradicition as the two are completely different beasts.

So if I was chatting with you I might use declaration in a fairly loose way, when i explained the concept of our and my I would restrict the term declaration to my alone. (And have done with my apprentices at work, and they ALWAYS get the idea right off. Wheras ive seen lots of nodes where people dont grok the distinction and then make subtle mistakes that would be totally obvious if they understood that my and our are barely related at all.

I mentioned it in passing above, but are you aware that there is no way to determine definitively after mentioning any other object in a package glob if the scalar has NOT been declared/created explicitly? Checking if *glob{SCALAR} is defined will tell you if the variable has been defined, but if its is undef you cannot say it hasnt been explicitly set to be so. (This is why Data::Dumper and other serialization modules will not output anything for the SCALAR slot if it is undef.)


---
demerphq

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