Damien Neil wrote:
> I like being able to treat arrays and hashes differently from other
> things. ... I know, just by looking
> at the expression, with absolutely no further knowledge of what the
> function and variable involved are, the general nature of what is
> going on. I know whether the function is receiving one argument or
> several. I can make reasonable assumptions about what will happen
> to the contents of the variable. I know something about what
> operations I can perform on the variable.
Sorry, this is exactly the argument we get from the C/C++/Java heads,
who find perl's lack of discrimination between strings and numbers so
distasteful. But if we can gloss over the difference between a string
and a number, we could (not that we should) also gloss over the difference
between an array and an associative array... or between an array and a
ref-to-array. Etc, etc.
> The real problem in the above is context -- when I see @a or %a, I
> know that it will behave in one fashion in list context, and another
> in scalar context. $a, on the other hand, may be trusted to remain
> the same no matter what the context.
Indeed, context is everything. There is no reason to expect (or demand)
that $ variables are any more or less "trustworthy" than other variables.
In fact, with tying, such trust is completely unwarranted. Not to mention
overloading.
So, using $ and @ to impose context is a reasonable thing to do.
Using @ to say "this variable can not be indexed by string" is not.
--
John Porter
