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). > >>> Iirc, there are some things in eina that raster didn't want to have in >>> the data type. I haven't looked into eina lately, but last time i did he >>> >> >> Well, having some subsystems of eina not desirable isnt an excuse to >> have 5 implementations of the same ;) >> > > We have two string pools and the lib I proposed would reduce it to one > implementation. Yes, i wasnt refering to the string pool itself, but to the list and hash, the stringpool already has consensus, but the latter no. > >> >> If stringshare pool already has a common API between ecore an evas >> ones, why not put that on the current effort of a common data type? >> > > I'm not sure if I understand you correct, but that's exactly what edt was > meant for. When i said "current effort" i meant actually the old edata or eina, as it has appeared on the ml and irc several times. > >> 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 think that a good thing to do is to actually compare both API's and >> try (if possible) to merge them, any volunteer? for the simplest use >> cases of course, get a data from the list and iterate over it. >> > > I don't like the two very much, but I believe we have to keep both > implementations. As I said above, I don't think it is worth the effort. And > about merging them, you haven't much space for that, because eet expects a > evas_list-like API. > ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
