On Thu, 21 Jul 2005, "TSa (Thomas Sandlaß)" wrote:
Matthew Hodgson wrote:
These rules are all fair enough - but they are then ambiguous for $::Foo.
Is that the leaf name variable Foo in your current (innermost) namespace?
It is not ambiguous if the sigil rules that expression. I assume
that the parameters of a sub are definining innermost names to
their body:
sub foo ( $param )
{
say $::param; # prints argument bound to $param
say $param; # same
say $OUTER::param; # prints value of result of a lookup
# that starts outside of sub foo
# but
my ::param $x = ::param.new; # look for param type info
Okay; if this is how $::foo works, then it makes a whole lot of sense :)
Or is it an attempt to dereference the disambiguated type Foo?
What is the use of reference to a type?
I have no idea - I was going on the basis of Larry's comment concerning
$::Foo looking a bit like an attempt to dereference ::Foo.
In other words you just can't use a sigiled expression where a type
is expected: my $::Foo $x; is just a syntax error. This is why I regard
the sigils as type mark-up. That means writing $Foo or $::Foo just
tells the compiler that you want to handle the item Foo.
Is there any reason why $::Foo could not do both, and not start by
searching your current namespace for a variable called $Foo... and then
start searching your current namespace hierarchy for a type called Foo
and try to dereference it (whatever that does)?
This is my position if I read the double negation correctly.
Oops - the double negative was a typo there; apologies... even then, I
think I understand that you agree that $::foo simply means an outwards
search of your current namespace scope for a variable called $foo.
Sorry if that wasn't clear initially. But I hope the above rants
clarify what I mean.
I hope that i'm on the right page now - thank you for taking the time to
clarify :)
Presumably it should behave in precisely the same way that $::('Foo')
does for sanity - does that search the current namespace for just types
or variables or both?
Not for sanity. $::Foo is just syntactic sugar for $::('Foo') because
'Foo' is a compile time constant. But $::( some_calculated_name ) might
not in general be evaluateable at compile time and thus forces the
compiler to generate symbolic lookup code which
1) calls some_calculated_value
2) starts lookup with the stringified return value
Note that because of the $ sigil it looks for something that does the
Scalar/Item role! We can consider the sigils as lookup filters.
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. Otherwise
the two $::... forms would be horribly confusingly different in their
behaviour, and I (and other future legions of newbies) would despair. :)
thanks again;
M.
