> [EMAIL PROTECTED] (Nathan Wiger) wrote on 14.08.00 in
> <[EMAIL PROTECTED]>:
>
>> Well, lexical variables don't belong to any package in Perl. They're not
>> in the symbol table, hence why others can't mess with them. That's why a
>> "my $var" is different from a "$pkg::var". The latter gets in the symbol
>> table, the former doesn't.
>
> I think Perl'd profit from using a structure similar to the following:
>
> 1. Package variables $package::var, presumably you'd have to declare those
> and the default would be
> 2. lexical variables,
>
> except that different from the current way, you'd have access to a stack
> of lexical symbol tables. (Doesn't mean it needs to be the same
> datastructure internally, just so long as you can access it with the same
> syntax.)
>
> So you'd find a global var via $package::{'var'}, and a lexical var via
> $STACK[3]{'var'} ($STACK[0] being where my() declares new variables, and
> $STACK[$#STACK] the symbol table where top-level my() declares file-scope
> variables).
Not to put a damper on the enthusiasm, but if you make lexical
variables accessible from outside the scope in which they are defined,
they aren't exactly lexical variables anymore.
I'm not sure what all the implications of this idea are. If you
simply make a variable from a higher scope accessible from a lower
scope even when a variable has been declared with the same name, I
don't think that is a problem. But, if you are thinking of routines
being able to access lexical variables they were never really meant to
see, there is grave danger.
> Except for access to the symbol table, that's very similar to what other
> languages have.
If everyone wanted it, then I guess I wouldn't stand in the way. It
reminds me of some unpleasantries with TCL, though. I think upvar and
the like are very cumbersome. Just an opinion, though. YMMV.
> Furthermore, in the "more rope" department, it might be possible to make
> local() work on my() variables this way.
YES! That is an integral part of this idea. It can even be
implemented if we keep dynamic variables around. Dynamic assignment
can be applied to any variable, if we want, although I think the
potential to overuse it on the part of a programmer will be very real
("more rope" indeed). Hopefully, with a new name (replace "local()";
RFC 19), people won't think of dynamic assignment before they think of
declaring their own lexical variables.
J. David
