Note: some parts of this may seem a bit like a flame. This is
unintentional.
Ken Fox:
# Brent Dax wrote:
# > What I'm suggesting is that, instead of the padlist's AV containing
# > arrays, it should contain stashes, otherwise indistinguishable from
# > the ones used for global variables.
#
# Lexicals are fundamentally different from Perl's package (dynamically
# scoped) variables. Even if you could somehow hack package variables
# to implement lexicals, it would waste space duplicating a symbol table
# for each instance of a lexical scope.
*How* are they "fundamentally different"? You keep saying this, but I
don't see it. In *functionality* what is the "fundamental difference"
between package and lexical variables?
# > The simple way to emulate this is to make sure that no subroutine
# > can see another's MY:: stash.
#
# Right. Sounds a lot like a pad to me -- each instance of a scope (sub)
# gets its' own copy of the variables. (By instance I mean activation
# record, not the symbol table definition.)
But in this case the pad is actually a full symbol table. The concept
is the same, the data structure is different.
# > There is a possible caveat with inner blocks--how does an
# outer block
# > get, er, blocked from accessing an inner block's my() variables?
# > However, I think this isn't really that big a problem, and
# can easily be
# > solved with properties:
#
# You don't understand lexically scoped variables. There isn't
# any run-time name lookup on a variable -- the compiler resolves all
# access to a specific memory location (or offset). All your fancy
# symbol table flag twiddling is slow, unreliable and unnecessary.
There *is* run-time lookup in some contexts, such as a string eval.
(Currently symbolic references are not another case--symrefs only work
with globals--but I think they should work with lexicals too.)
In the end, all I'm doing is suggesting an alternate implementation
which should reduce our workload and make many concepts which currently
don't work with lexicals work correctly. If there are big, huge
problems with the alternate implementation I'm proposing, please explain
them to me.
--Brent Dax
[EMAIL PROTECTED]
"...and if the answers are inadequate, the pumpqueen will be overthrown
in a bloody coup by programmers flinging dead Java programs over the
walls with a trebuchet."
