Bart Lateur writes:
: Er... hip hip hurray?!?!
:
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs. A highlander
: variable would get you that: that if a hash %foo exists, the scalar $foo
: would automatically be a reference to that hash.
:
: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?
$foo{THERE} always means the hashref in $foo. %foo{THERE} always means
the hashref in %foo. %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref. &foo by itself in
a scalar context means a coderef. It's gonna be pretty consistent.
Likewise, bare @foo, %foo, &foo in function prototypes will default
to supplying a scalar context, so they don't eat arguments. The final
argument will have to be specifically marked if you want it to eat
up arguments. And we'll probably distinguish eating a list in list
context from eating a list of scalars, so you could pass a list of
arrays easily to a variadic function with each variable name in
scalar context so as to produce a reference.
This is a little hard to explain, but I intuit that it will turn out to
be intuitive.
Larry
