# -----Original Message-----
# From: Sam Tregar [mailto:[EMAIL PROTECTED]]
# Sent: Sunday, September 02, 2001 1:23 PM
# To: Brent Dax
# Cc: [EMAIL PROTECTED]
# Subject: RE: Should MY:: be a real symbol table?
#
# On Sun, 2 Sep 2001, Brent Dax wrote:
#
# > but in that case the inner my($x) could be translated to
# > temp($MY::x)--the behavior is basically the same.
# (Actually, if pads
# > are replaced with stashes, is there any situation where
# my($x) can't be
# > translated to temp($MY::x)? Hmmm...)
#
# Closures, for one. File-scoped lexicals for another.
# Lexical variables
# are very different beasts from package variables. They are
# not compatible
# in some significant ways.
Okay, I forgot to account for the fact that we'd have to increment the
refcount for every inner scope a my() variable is referred to in.
That's not terribly hard, is it? File-scoped lexicals are basically the
same thing--increment the refcount for every inner scope they're
referred to in (unless they have some other special behavior I'm not
aware of).
# Now, that said, we'll need to do something better than pads to support
# %MY. If that means full-blown symbol tables for every scope... Well,
# I'd be surprised. There's a reason lexical variables are faster than
# package variables and I imagine we'd like to keep it that way.
I imagine they'd *still* be faster than package variables, if only
because it would check for a my() variable by that name first. Since we
don't have to deal with autovivifying my() variables, we can probably
resolve many lookups at compile time at least to the correct stash
entry, which will make tighter loops than a full lookup each time. (In
other words, if we know all the my() variables available, we can do the
lookup at compile time to get the address of an RV to the actual SV.)
--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."
