How global the defaults?

[Dan Sugalski]

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
d...@sidhe.org have teddy bears and even
teddy bears get drunk