On Wed, 20 Jul 2005, "TSa (Thomas Sandlaß)" wrote:
Matthew Hodgson wrote:
I'm very surprised that package variables end up in OUR::, however -
because surely they're not necessarily lexically scoped - and the whole
point of 'our' was lexical global scoping, right? :/
Sorry, what is 'lexical global scoping' e.g. compared to
non-global lexical scoping? Is it not so, that conceptually
a program that is loaded from several files can be seen as
a complete nesting of all used packages, modules, classes
etc. where the file scopes are replaced by pairs of braces?
Sure - a nesting of namespaces as opposed to lexical pads.
The care takers of OUR:: are the package, module, class and
role meta classes while MY:: is handled by everything in braces
basically.
Well, when I saw the pseudo-namespace OUR::, my first thoughts were that
its contents would be the current our()d variables which we can access in
a non-qualified manner in our current lexical pad. Not that it was
actually all the package variables in our current namespace, be they
currently lexically accessible or not. Surely this pseudo-namespace
should be called PACKAGENAME:: or something rather than OUR:: in order to
avoid this confusion?
Whilst:
% perl -we 'use strict; { our $foo = "foo"; } warn $::foo'
makes sense in perl 5, I still maintain that:
% perl6 -we '{ our $foo = "foo"; } warn $OUR::foo'
is kinda confusing ;)
I've tried to wrap my head around all these behaviours of :: and
summarize them here for future readers: inevitable corrections more than
welcome ;)
Foo # leading sigil: disambiguates Foo as being in type
space
$Foo::bar # trailing sigil: indicates preceding term is in type
space
$Foo::Baz::bar # separator: type space hierarchy separator
($foo) # special case leading form which behaves more like the
trailing sigil & separator form for building up type
terms from expressions, as ($foo):: would be ambiguous.
Isn't it easier to say that :: is a unary/binary, right associative
pseudo operator with the following properties:
1) whitespace around :: is not allowed
whitespace to the left stops outwards scanning
this allows ?? ::
2) its rhs is the leaf name you want to refer to
3) the lhs is the namespace path to that leaf
4) a * wildcard starts lookup from the root
(for details of *Foo versus *::Foo see above)
5) parentheses cause symbolic runtime lookup, otherwise
the lookup is at compile time and needs pre-declared
names because there are no barewords
6) a sigil determines the type you want to refer to:
no sigil means autoderefed---that is called---Code
whitespace means a type (if more than one leaf
matches because the name is overloaded the least
upper bound (lub = any type junction) supertype is
returned.
These rules are all fair enough - but they are then ambiguous for $::Foo.
Is that the leaf name variable Foo in your current (innermost) namespace?
Or is it an attempt to dereference the disambiguated type Foo? Or is it
like perl5, shorthand for $*Main::Foo?
Is there any reason why $::Foo could not do both, and not start by
searching your current namespace for a variable called $Foo... and then
start searching your current namespace hierarchy for a type called Foo and
try to dereference it (whatever that does)?
Presumably it should behave in precisely the same way that $::('Foo') does
for sanity - does that search the current namespace for just types or
variables or both?
M.
