Hey, The general policy for GLib is that utility functions which are useful (and used in) several projects are considered for being added to GLib. To me, a functional programming approach using GLists is not something which every project is going to use. Is there any harm in keeping it as a separate library? There’s nothing stopping projects from linking to GLib *and* GXLib. :-) The command line parsing stuff you have looks a bit more widely applicable. Were you considering merging those into GLib? http://www.djcbsoftware.nl/code/gxlib/gxlib-Command-line-parsing.html Anyway, nice work on GXLib. It looks well documented. Philip On Sun, 2017-04-23 at 21:46 +0300, Dirk-Jan C. Binnema wrote:
Hi All, A while back, I wrote some functions for functional-flavored programming with GLib. It's fully documented[1], has tests, etc. It would (for me at least) be useful to have some of these functions in GLib-proper, but I suspect the GLib-maintainers are not /too/ eager to accept contributions to GList... anyway, perhaps its useful for others. As a simple example, suppose we want to calculate the sum of primes up to 100 (a common task after all): ,----int sum; GList *nums, *primes; nums = gx_list_iota (100, 1, 1); primes = gx_list_filter (nums, (GXPred)gx_is_prime, NULL); sum = gx_list_sum (primes); /* => 1060 */ g_list_free (nums); g_list_free (primes);`---- There's also folding, mapping etc. See a short article about this: http://www.djcbsoftware.nl/2015/10/04/functional-glists/ (2015?! time does fly). Am still developing it though. Repo: https://github.com/djcb/gxlib Docs: http://www.djcbsoftware.nl/code/gxlib/ Best wishes, Dirk.
Attachment:
signature.asc
Description: This is a digitally signed message part