[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RFC: modules for generic unordered sets and mappings
From: |
Bruno Haible |
Subject: |
Re: RFC: modules for generic unordered sets and mappings |
Date: |
Fri, 2 Jul 2010 16:01:10 +0200 |
User-agent: |
KMail/1.9.9 |
Hi Paolo,
> I disagree that all these should be in gnulib. In fact, I think ADTs
> don't belong there.
Why not? The '*-list' modules are used by gettext, m4, pdf, the 'clean-temp'
module, git-merge-changelog. They clearly satisfy the gnulib entry criterion
of " "portability" and/or common files for GNU projects ". I expect the
'*-set' and '*-map' to be used in the same way.
> Maintenance and, secondarily, RAM cost.
Maintenance? For the *-list modules, there were 0 changes in 2010 so far,
3 changes in 2009, 1 in 2008, 2 in 2007. This is not a lot.
RAM cost? Do you think linking with a shared library with 100 modules costs
less RAM than having 5 of these modules linked in the executable? Also, do
you frequently run 'm4' at the same time as you view PDF files or run
'msgfmt'? I think, in the current situation, linking with a non-shared library
is still perfectly fine.
> libunistring and crypto stuff are borderline
> already (because some of the modules actually make sense in gnulib, e.g.
> uniwidth and sha1), but these should be in a shared library, not a
> static one.
You have seen (on the occasion of libunistring) that when there is enough
demand for having the code in the form of a shared library, we can release
the code in this form, while still keeping it available in gnulib. For the
moment, however, no one has asked for having the '*-list' modules in a
shared library.
> In fact, glib or libnih probably provide all that you need already
Yes, there are many libraries that provide some kind of container data
structure: avl, gdsl, libast, libh, libmba, libscl, libslacj, libtc, libuniqx,
sglib, skalibs, and many others.
None of these libraries provide the containers as _abstract_ data types.
Always only concrete data types, with a different API for different list types.
Also, the reason I try not to use glib is that its error/bug handling is too
relaxed (prints a message to stderr, but no easy way to debug it), its
thread implementation is partially overkill (the condition variables, I mean),
and the autoconf macro for linking with it is non-trivial.
Also, libnih is under GPLv2, not GPLv2+.
Bruno