Front page | perl.perl6.language |
Postings from July 2005
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.
Thread Previous
|
Thread Next