From: Lyle K. <te...@ke...> - 2001-04-09 20:22:13
|
* enl...@li... (enl...@li...) wrote: > Enlightenment CVS committal > > Author : smugg > Project : e17 > Module : libs/ewd > > Dir : e17/libs/ewd > > Log Message: > -lewd ;P > A lib for simple data types, currently it only has a doubly linked list, > the plans for it is to have a single list, a hash table, string functions, etc > and all these will be very powerfull I'm not attacking you specifically, but.. we have way too many of these. Can we please stick to and improve only one? We have giblib, ewd, some stuff in evas, some stuff in imlib2 (hashes, caches), I think pabs has one outside cvs.. we don't need 3000 of these. We don't need to keep proving we each took data structures. Please settle on something to provide each of the following and stick with it: - OS abstraction (this is the one thing I love about glib.) - singly linked lists - doubly linked lists - a flexible hashtable implementation - trees (at least unbalanced, avl, and splay, though red-black would be cool too) - heaps - stacks - memory pooling? (but *not* used internally) - priority queues - some way to specify a policy (via functions) for memory management for the library on a project-by-project basis At least that. I probably left a few out (my data structures book is at home. :) But let's stop reinventing the wheel, huh? I mentioned why it makes sense not to use glib (primarily, it's heavily tied to gtk+, which becomes an issue if you just want data structures support), but there's no reason to have so many libraries with completely duplicated functionality. I also see a lot of discussion on irc between developers about algorithms for image data manipulation, and it sounds like people are semi-reimplementing things.. if that's the case, we should have just a simple graphics library implementation, maybe even divide imlib2 into an "algorithms" library and a "load/save" library? This is more of a brainstorming thing, though. There's a good chance it's a horrible idea. term |