On Thu, 16 Oct 2003, Leopold Toetsch wrote:
> Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
> > The IMCC_INFO does not need to be part of the interpreter.
>
> I don't like to have global state variables around. I don't know yet,
> what happens if 2 interpreter threads both do eval()...
If it's per-interpreter, nothing, since each thread should have its own
intepreter. (Though I can see some potential deadlock issues, though
that's not specific to this)
> >> It will be replaced by a still simple but expandable hash finally.
>
> > Ok, granted. Parrot-Strings might be a little heavy. But introducing
> > yet another hash implementation does not seem right to me either.
>
> We need for sure a hash with plain cstrings as keys too. The code in
> hash.c seems rather heavy (and slow) to me, callbacks would slow down it
> additionally.
It should all be black-box--if the code in hash.c is nasty, it can
certainly be rewritten. (Though I'd keep in mind the need for a random
seed in the hash, and Unicode makes hashing somewhat interesting)
Dan
