Hi.
There may be a flaw in the actual design of the hash module. A
pdf_hash_t manages the memory of its entries, so it will invoke a
"memory disposal function" when entries are removed from the
hash. That is fine, but right now we are specifying the 'element
dispose' function in hash-construction time:
pdf_hash_create (pdf_hash_key_dispose_fn_t dispose_key_fn,
pdf_hash_element_dispose_fn_t dispose_fn,
pdf_hash_t *table);
The problem with this schema is that the values stored in a hash
usually are heterogeneous. That is the case, for example, of the
filter parameters or file properties. The actual API is not
appropriate.
As I see it there are three alternatives:
1) To let the management of the memory of the values to the entity
using the module. This sound really bad for me, since the client
would need to dispose all the values contained in the hash before
to destroy it. It is error prone.
2) To specify the element memory disposal function at element
insertion time, like:
pdf_hash_add (myhash,
"key",
a_text_variable,
memory_disposal_function_for_text_variables);
In this case would be quite useful to have some element disposal
functions written for the several pdf_*_t types, including the
pdf_hash_t one.
3) To change the way the hash module works by introducing
typed-values. That is, to restrict the contents of a hash entry to
a predefined set of types, like:
pdf_hash_add_text (myhash,
"key",
a_text_variable);
pdf_hash_add_u32 (myhash,
"FileSize",
pdf_u32_value);
In this case we will need to expand the pdf-hash API to be able to
ask the type of a given entry:
pdf_hash_entry_type_t pdf_hash_entry_type (myhash, "key");
Gerel, what do you think about this issue? What would be your
preferred solution?
