Here's a question for people to ponder.
I'm adding facilities for a default character set and encoding for parrot to use in the absence of any other reasonable information. This is what text strings will use unless code explicitly changes it, and there'll be a build-time setting at some point to choose the default.
That's fine.
The question, though, is *how* global this stuff should be.
I can easily see it being a one-shot, set on initial load of parrot, thing, in which case sticking the pointers into module statics (or, I suppose, process globals) is a reasonable thing to do. This is also likely the fastest way to access the data, since with exposed globals there's no need for function calls or anything to get at the pointers.
I can also see this being a per-interpreter setting, in which case the pointers can get stashed into the interpreter. This skips the globals and is likely almost as fast as globals, which is fine.
If, though, we put these into the interpreter, then there's the question of whether they should be scoped -- that is, should they be preserved as part of the interpreter context along with things like the namespace pointer, current lexical pad, and suchlike things.
Globals are fastest, but, well, global.
Stuffed in the interpreter is slightly slower, but no globals. Plus each interpreter could theoretically have its own default.
Made part of the interpreter context is the most flexible, but in addition to being slower to access it'll also slow down sub calls since it's that much more data to track.
At the moment I'm leaning towards the default being a process-global thing -- it'll be fastest, and we can always lift the restrictions later. I'm open to suggestions, though, so feel free to discuss the color of this particular bikeshed...
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
