On Fri, Sep 17, 2004 at 09:41:37AM -0500, Jonathan Scott Duff wrote:
: Maybe I'm just being curmudgeonly, but is this really that useful to
: have such shortcuts? I presume that there will be alternate ways to
: access the same information (like maybe a special hash
: (%*WHICH{'package'} and %*WHICH{'file'}) or some other suitable
: abstraction (maybe there's an object that represents the program state
: that you can query $*PROG.file, $*PROG.line, etc.))
Except it's not program state, which rightfully belongs in the *
namespace. It's lexical scope state, which is a compiler state, and
has nothing to do with run time, or the process state. The process in
question might not even exist yet! That's the fundamental distinction
between the * and ? namespaces.
: But is it really worth the the secondary sigil?
I believe so. We used to have __FILE__ and __LINE__, which had all
the problems of not being variables, but all the advantages of being
single tokens that can be substituted in at compile time. I'd like
to fix the one without breaking the other. I don't see any reason
to stuff a bunch of unrelated items into the same hash, other than
avoiding cluttering up a namespace, and the secondary sigil works
for that just as well. But I think cluttering up the user's mind
with a named abstraction is not terribly useful. The "whichness"
of C<?> happens subconsciously, whereas having a named hash forces
people to think, "Now what was that consarned thing called again?"
People want to think, "I want to interpolate the line number here".
They don't want to think, "I want to interpolate the line number
which is a member of this data structure for some strange reason here."
Larry
