> `pdf_status_t pdf_hash_mapkeys (hash_table,
> pdf_hash_mapkeys_fn_t func,
> void *client_data)'
>
> Apply FUNC to each element contained in HASH_TABLE. The prototype
> of FUNC should be:
>
> pdf_status_t func (pdf_hash_t hash_table, char *key, void
*client_data)
>
> FIXME: Should we define an order???
If there exists a situation in wich order is relevant then we can define an
iterator type over the keys or elements instead of the "pdf_hash_mapkeys()"
function.
I agree. That solution is much better. It is also consistent with the
list module design.
We should determine an order for the iterators. In a similar function
in the Adobe Acrobat SDK they use the following order schema:
"Keys consisting solely of digits are enumerated first, in numeric
order (assuming they are not padded with zeros at the front, which
will confuse matters). Non-numeric keys are then enumerated in
strcmp order."
I think would be good to follow the same rule in our implementation.
> I don't know how the enum "pdf_hash_value_type_e" is going to be
> used yet.
>
> We are not going to use that type, since we are working with generic
> pointers to store data into the hash table. The definition of
> `pdf_hash_value_type_e' in gnupdf.texi should be deleted.
>
I agree.
I'll add the rest of the functions you suggested.
Thanks.
