In message <[EMAIL PROTECTED]>
        Simon Cozens <[EMAIL PROTECTED]> wrote:

> As things stand, that won't work, because you're doing a string lookup in one
> of the core functions, and you still need some way of registering incoming
> stuff. With an enum, you can keep hold of a fake encoding_max, and hand
> encoding_max++ to the initialisation function for each encoding.

Well there won't be any point in it being an enum rather that an 
integer unless some of them are going to be preallocated. I'm not
sure if the encoding and character types will need to know their
own index numbers but if we do then they can be told at initialisation
time, yes.

I absolutely intend that the current hard coded strings in the core
will go away in due course though. When you look up an encoding or
character type by name it will first check a hash table or something
to see if it is already loaded and if not it will look for it on disk
and load it in, allocate it a number, and add it to the hash table
for future reference.

Hence the current strcmp junk in the lookup functions will go away.

In much the same way the byte code will have some sort of table of
names which it will look up as it is loaded rather than the current
hard coding of name to number mappings in the byte code.

So all I need now to make all this work is hash tables and dynamic
code loading ;-) Any volunteers...

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu

Reply via email to