On Tue, 19 Jul 2005, Larry Wall wrote:

On Tue, Jul 19, 2005 at 07:25:35PM +0100, Matthew Hodgson wrote:
:
: So the question is: what is the correct syntax for referring to package
: variables in the default namespace?

The * looks like a twigil but it isn't really.  It's short for "*::",
where the * is a wildcard package name, so in theory we could have
$=*foo, meaning the $=foo in the *:: package.  (But most of the
twigils imply a scope that is immiscible with package scope.)

So, if I understand this correctly, the conclusion for referring to the default program namespace is $*Main::foo - which is shorthand for $*::Main::foo, which pulls the variable $foo out of the globally-rooted namespace called Main. I'll plonk some tests into pugs to try to steer towards that...

In terms of resolving non-fully-qualified namespaces, presumably $Main::foo would work most of the time, assuming that you weren't currently within any package/module/class namespace scopes called Main - as S02 says 'the "*" may generally be omitted if there is no inner declaration hiding the global name.'?

: Also, what is the correct syntax for referring to package variables in
: your 'current' namespace?  $::foo?  $?PACKAGENAME::foo?
: $::($?PACKAGENAME)::foo?  %PACKAGENAME::<foo>?

That's currently:

   $OUR::foo

right... I guess that goes with $MY:: and $OUTER:: in S06 and their respective hash access methods.

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? :/

is being able to:

% perl6 -e '{ $*Main::foo = "foo"; } say $OUR::<$foo>'

really a feature? Or is OUR:: actually intended to include non-lexically scoped package variables too as a special case?

I'm not sure whether $::foo
is usefully distinct from $foo these days.  It almost seems to imply
that ::foo is in type space and we have to dereference it somehow.
There's a sense in which :: only implies type space after a name.
We somehow seem to have the situation where :: is simultaneously
trying to be a leading sigil, a trailing sigil, and a separator.

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.

I assume that I am correctly following your lead in referring to package/module/class namespaces as 'type space' here...

As regards $::foo, making a special case for it being a synonym for $*Main::foo be yet another complication entirely without precedent in the current behaviour. But then again, using $::x in the past as a quick way to disambiguate between lexical & package variables in simple package-less scripts was quite handy...

thanks hugely for the quick feedback :)

M.

Reply via email to