On Wed, Jul 9, 2008 at 2:40 PM, Jorge Luis Zapata Muga <[EMAIL PROTECTED]> wrote: > On Tue, Jul 8, 2008 at 8:52 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: >> Jorge Luis Zapata Muga schrieb: >>> >>> Having a common agreement isnt easy but we should make one. Cedric >>> ideas of providing a common API and just do some macros is useful, i >>> agree that the structure of the code using might have to change, but >>> either way a list API of any kind, is more or less common, you iterate >>> over it with the next and prev and you get data, the rest is an >>> extended API. A big effort has to be made from us to port everything >>> on cvs to it, but one time or another this has to be done. >>> >> >> I don't think that an unification of the list APIs is possible. And even if, >> we'd end up to change thousands of lines of stable code, which was tested >> over many years. And that without any reasonable benefit. > > Here you'll find a simple implementation of ecore_dlist using > evas_list as its backend > http://code.google.com/p/efl-research/source/browse the module is > called ee_list, you'll see that not every function is implemented but > enough to see that there's no difference in the API or in the result. > So in my opinion it is possible. IMHO Is not a problem of possibility > but of will, if we want to have only one double linked list > implementation we should do the effort. The benefits are several, > beside consistency on the code, is good for newcomers, every time a > new dev come around he asks what list/hash to use and what toolkit, > etk/ewl ? (but a toolkit isnt core, data types are).
I would also add that it will improve memory profile as we will use the same memory pool for all list. >>> eina should be included into cvs, im ok with that, im kind of >>> restrictive to indentation changes, but that's another matter :) >>> >>> In my opinion the first thing that should be done is add the svn code >>> into cvs, then add your stringshare there and slowly port the rest, >>> eet is a special case because it already has a release, so it should >>> depend on another releasable code (eina) which isnt complete, so eet >>> might have to be last one to be ported. >> >> Putting eina now into cvs doesn't help anyone at the moment. There are two >> ways we can go: >> >> 1. First we start with a little lib, where we put step by step code into it, >> we agree with that it belongs into the common lib. That's what I tried with >> edt. >> 2. We first discuss how the common lib needs to be en bloc and in detail and >> then change eina to match the result of the discussion. And move it then >> into cvs. >> >> It looks like most people here prefer the second way. I will say we have a third option. Put a common lib in cvs now. Then slowly move stuff around to the new system. With current work from caro with Evas_Data.h we should be able to provide a set of macro that will help do the move quickly. This move should not impact performance at all (and looking at eina current code, I don't see how it could change something regarding that). -- Cedric BAIL ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
