[zeromq-dev] Proposal for a revised zlist API

[Pieter Hintjens]

On Mon, Sep 8, 2014 at 6:42 PM, Goswin von Brederlow <goswin-v-b at web.de> wrote:

> Urgs.

:-)

> If zlist gets deprecated then there needs to be a new list (zring)
> that preserves the strict fifo ordering and simplicity of a list.

We don't need to deprecate zlist then, rather we can keep it as the
simple list container.

> Merging them together generaly just combines
> the bad aspects while loosing the good.

Not really. I've experimented with the zring hybrid and it works very
neatly, and it solves the case we have often, of keeping a list+hash
of items. In fact the only case I've seen of code using two containers
for the same data.

> This new mix
> with a hashtable makes the class unusable from an API point too.

How? If you don't use the keyed calls, it works just like before.

> And you can't
> detach/delete an item by key, which would be the only point in all of
> this for me. (Note: I do need that zring_node_t * return value for
> append back by the way).

If you have keys for an item then you use _insert to store them, and
then _delete to remove by key.

> On the other hand the extra arg is invaluable when combinging or
> stacking containers or stacking of free_fn functions.

Which is a use case that zring now kills off. Unless you have other
mixes of containers.

It is demonstrably simpler to allow zring to do both list and hashing
than manage two containers in the app, and adding user pointers just
complexifies further.

> size_t czmq_hash_fn (void *item, void *hash_private)

Sure, yes. The hash item needs to also get the key, if any, used to
insert the item.