develooper Front page | perl.perl6.language | Postings from July 2005

Re: Referring to package variables in the default namespace in p6

Thread Previous | Thread Next
From:
Matthew Hodgson
Date:
July 21, 2005 07:35
Subject:
Re: Referring to package variables in the default namespace in p6
Message ID:
Pine.LNX.4.61.0507211457250.11551@phoenix.arasphere.net
On Thu, 21 Jul 2005, "TSa (Thomas SandlaƟ)" wrote:

> Matthew Hodgson wrote:
>> I guess $::('Foo') was a bad example - $Foo="Foo"; $::($Foo) would have 
>> been better at illustrating my point - which was that if $::($Foo) 
>> searches outwards through namespace for a variable whose name is held in 
>> $Foo, then $::Foo should end up referring to the same variable.
>
> Let me restate that in my own words. You mean that a symbolic runtime
> lookup $::($Foo) with the value of $Foo at that time shall be cached
> in the immediatly surrounding namespace and that cached ref is then
> accessable through the syntax $::Foo?

Hm, I seem to be making a bit of a pigs ear of explaining myself here, but 
thank you for bearing with me.  What I was trying to confirm was that 
if you create a variable in your immediately surrounding namespace:

$*Main::foo = 'bar'; # (assuming you are in the default namespace)

and a variable containing the string 'foo':

my $varname = 'foo';

then the principle of least surprise suggests to me that the result of 
evaluating $::($varname) should be identical to that of evaluating $::foo.

I wasn't getting hung up on whether $::($varname) should somehow be cached 
to avoid a dynamic lookup based on the current value of $varname every 
time.  And I assume that if $*Main::foo hadn't been created, assigning to 
$::($varname) would create it as expected (again, without any caching of 
$varname).

My confusion initially stemmed from chat on #perl6 about $::Foo and 
$::('Foo') being Very Different Things - and the fact that there was ever 
any confusion over whether $::foo was your 'closest' $foo variable or 
something else.

> BTW, I wonder if $::() means $::($_) :)

hehe; that would almost be nice... :)

>> Otherwise the two $::... forms would be horribly confusingly different 
>
> Sorry, they are the same thing: namespace lookup. But without ::() the
> compiler does it at compile time for bareword resolving. Without a sigil
> in front the result can be used where a type is expected:
>
> for ("blahh", "fasel", "blubber") -> $name
> {
>>> ($name).new;
> }
>
> We can consider the equivalence of $foo and $::foo as TIMTOWTWI.
> I dought that assigning two different meanings just because their
> are two syntactical forms is a good idea.

Fantastic - all my fears are allayed, then.  $::foo is $::('foo') is $foo 
(assuming it hasn't been our'd or my'd), and all is well in the world.

>> [lest] I (and other future legions of newbies) would despair. :)
>
> You consider yourself a 'legion of newbies' ;)

Well, earlier I may have been legion, but I think i've regained my karmic 
balance a bit now... ;)

cheers;

M.
Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About