On Mon, 2 Jan 2006 16:33:51 -0500 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Monday, 02 January 2006, at 12:46:32 (-0600), > Nathan Ingersoll wrote: > > > I don't think there is a very cohesive plan on list use atm. I've > > heard a few rumblings of people saying "ecore lists suck" or "evas > > lists suck" but as usual it's a case of choosing the best tool for > > the job and knowing when each is appropriate. > > And thankfully the data structure names make it very clear to > developers what the basic implementation and usage considerations are > for each list type. Any idiot knows the difference between "List" and > "List2." >:I i think i need to give a small history class. this has nothng to do wi9th taking a lesson from libast. list2 was the ORIGJNAL ecore list for INTERNAL ecore use only - not as an api to be used outside of ecore. it was not called list2 then - just ecore_list - and it was there becasue there was NO DEPENDENCY that provided a linked list. it was built as a simple internal linked list system to hold lists of timers, event handlers etc. it got renamed when ewd (ewl's data struct lib) was moerged into ecore as ecore_data. thus ecore_data now provided an EXTERNAL api for ecore_list and the existing code was just renamed to ecore_oldlist. we made it list2 to save typing. it's simply that the way the list mechanisms worked was DIFFERENT historically. evas has its own list system as it needs a LOT of lists and actually needs 2 KINDS of lists (generic pointign to item lisst (evas_list which is made public for general usefulness as its used internally anywway) AND evas_object_list (internal only - requires object include list header struct at the start of its struct - ie inheritance) which saves allocs and list searches for removes if you already have the object u want, and also assumes the object will lexist in 1 list only (if it is references in other lists evas_list is the way to go). but as i said - these exist because evas doesnt rely on ecore and needs its own lists (and actually is historically older than ecore). since evas and ecore share no common dependency there is no good place tyo put a shared list mechanism - also each is quite engrained in its own and changing it is a lot of work. as nathan said - it's very historical in nature and ecore_list2 and evas_list and evas_object_list are very similar in that they are simple double-linked lsist with minimal accounting. (btw nathan - ecore_list2 does keep a pointer to the last member :) so its overhead per object that uses it is 3 pointers). ecore_list2 is very much identical to evas_object_list - designed for tracking objects in 1 list only with DIRECT access to the list node they are stored in from the object itself without a list search needed at all (ie O(1) remove, O (1) append, O(1), prepend). they are very efficient at what they were intended for and quite minimal, considering (saves an alloc per list node (no allocs in addition to the object), also O(1) on the most common operations etc.) > I've said it before, and I'll say it again. Evas and Ecore really > need to take some lessons from libast on how to provide multiple > implementations of a common data structure type with a single > interface and easy switching between selected implementation in each > case. Or at least on how to name a list implementation so it hints at > the underlying mechanism. :P > > Michael > > -- > Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> > n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) > ----------------------------------------------------------------------- > "Here, let me get my thumb off her breast so you can fully appreciate > her." -- Beth O'Hara > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
