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?
My understanding is that the expression $::($Foo) is *always* triggering
dynamic lookup with the then current value of $Foo. If this is not what
you want then say so with one of these:
my $FooCache := $::($Foo); # everytime when dynamic scope is entered
state $FooCache := $::($Foo); # once and for all
Otherwise
for ("blahh", "fasel", "blubber") -> $name
{
$::($name) = 42;
}
wouldn't be really usefull. BTW, I wonder if $::() means $::($_) :)
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.
in their behaviour, and I (and other future legions of newbies) would
despair. :)
You consider yourself a 'legion of newbies' ;)
--
TSa (Thomas Sandlaß)
