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.

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.)