Jorge Luis Zapata Muga schrieb: > 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.
Indeed, that way 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. Sure it isn't a big deal to write this wrapper and with a little bit more work, it is also possible to support index counting, which I consider as part of the API. > 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). > That is my main problem with it. I don't see any real benefit doing it. There will be still two implementations (APIs) around, so the new dev will still ask which one to use. And sure you will share code between ecore_dlist and evas_list, but ecore_list and ecore_dlist are sharing code already, this overlap will then be lost. On the other hand you will increase the node size by one pointer without having any improvement, except maybe the mempool mentioned by cedric. ------------------------------------------------------------------------- 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
