Re: [PATCH] *-map, *-omap: Allow passing NULL to search

[Bruno Haible]

Hi Colin,

> So far, the only extra supporting code I've felt the need to write
> around Gnulib's container types consists of (a) equals/hash/etc.
> implementations for relevant types

Yes, these are definitely something the application package needs to
provide.

> (b) convenience wrappers for creating lists of strings and suchlike

Yes, it would really be good to have such wrappers automatically
generated (like the compiler does for C++, when you have templates).
Maybe a concept of a "parameterized gnulib module" would help? It
would create source code by substituting application-provided tokens
into gnulib-provided template code.

> (c) iteration macros;

How do your macros look like? I haven't provided such macros, because
all ways to define such macros I can imagine have major drawbacks.
Maybe yours are better?

> For what it's worth, I was taking things like gl_list_iterator_next's
> handling of nodep as a partial model.  It's clear that it's sometimes
> acceptable to have NULL checks in similar situations in this code

Apparently I didn't think as strongly at the NULL checks when I
implemented these. Or maybe I found it hard to explain why we would
have 2 functions gl_list_iterator_get_next (which produces the value)
and gl_list_iterator_next (which ignores the value).

> (d) map/omap "contains" checks.  The last of those feels like it's filling
> in a gap in the interface
> ...
> the only thing I've noticed in the
> various containers APIs that really feels like an interface omission

OK, I can add such a function, as an inline function in gl_map.h and
gl_omap.h.

> choice of function name (I prefer "contains" over "entry_exists").

'gl_map_contains'? Hmm, one would expect that it takes the key and the value
as arguments.
'gl_map_entry_exists'? Likewise.
Probably I'll name it 'gl_map_haskey'.

Bruno