Russ Allbery wrote:
>
> > All variables should be C<$x>. They should behave appropriately
> > according to their object types and methods.
>
> No thanks. I frequently use variables $foo, @foo, and %foo at the same
> time when they contain the same information in different formats. For
> example:
>
> $args = 'first second third';
> @args = split (' ', $args);
> my $i = 0;
> %args = map { $_ => ++$i } @args;
>
> This is very Perlish to me; the punctuation is part of the variable name
> and disambiguates nicely. I'd be very upset if this idiom went away.
It's already withered away some in perl5. Functions can return lists or
scalars with no distinguishing marks, which was harmless until the
advent of lvalue subs. Now you have $object->listmember = (1,2,3);
$object->scalarmember = 42;. Anyone up for an RFC on allowing a leading
@, $, or (?) % to set the context of a function call? ;-) (Maybe there's
one already, I haven't been keeping track.)
I would very much hate to see the prefixes go away or merge into a
single one, but I'm not so sure I agree with Russ. I've had to teach
lots of beginners that even though $x refers to scalar x, $x{...} refers
to %x, but don't think of it that way because the $ is saying what value
you're getting back, not which variable you're using, unless you're
calling a function, or...
I'll just say I wouldn't mind having a stricture forbidding $x and %x in
the same package. I've fairly frequently used code like the above, but I
don't really like that code in the first place because the only purpose
for the $args and @args is as temporaries. I like the way mjd describes
it: this is "synthetic" code. If you really did have distinct
long-lived variables with the same name, then I bet it would be
confusing. Either you're maintaining some consistency invariant between
them, and you have to do that manually, or they're unrelated and they'll
collide in readers' brains.
