On Tuesday, March 16, 2004, at 02:01 AM, Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
- Did exception handling ever get fixed? (I had submitted a test case ages past - Last I saw was Leo saying "patches welcome". It was a COW bug, IIRC.)
The COW bug is fixed. Using exceptions should work.
Very good, thanks. That'll let me get associative arrays finished up.
- I was told ages past that I should use "global" for tcl's global variables to play nice with others... What is the "right" way to store my interpreter's global state, then?
Well just use the global ops.
global "tcl_globals" = the_hash # store .. pref = global "tcl_globals" # fetch
PerlHash that maps command names to the builtin functions). I suppose I
could create my own pad, or even an object... but then how do I access
it without storing it in a global?
Pads are for lexicals inside subroutines. Using an object or an hash doesn't differ, you have to store it somewhere (or pass it around).
Why not just use the global opcodes?
leo
Because global variables in tcl are different than global state internal to my interpreter, and it would probably be sporting of me to only expose the variables defined in the language, rather than those used internally by the bytecode - so, if global opcodes are the way to store global language variables, then I need a way to hide my private data.
My initial thought had been that tcl's "global" was really more like outermost lexical scope, so I was going to blissfully continue using "global" for my personal junk, but the respondent seemed to think this was not a good thing for interoperability.
--
Will "Coke" Coleda will at coleda dot com
