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ß)


Reply via email to