On Tue, Jul 8, 2008 at 10:47 AM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote: > Vincent Torri schrieb: >> >> I think that Hisham wants you to put your code in edata, and not create >> another lib. >> > Unfortunately, it isn't that easy. We have two (or with other counting 3 > or 4) list implementations and two hash implementations. Since their API > is totally different, especially for the lists, we cannot simply choose > one of them and port the rest to that API without an incredibly huge > amount of work. So the only way we can handle it is to have both > implementations parallel in the data lib. But how are we going to name > them? Maybe we name the evas_list edt_nodes or we name the ecore_list > edt_slist and the ecore_dlist edt_dlist, so we can use edt_list for the > evas_list. For the hashs the situation is a bit better. After Nathan has > his ecore_hash improvements in. We can make the evas_hash a wrapper > around it. But we still need to think about a name for it, maybe > edt_strhash. Where we can really unify stuff is for ecore_list2 and > evas_object_list, i think we can take there turran's eina_inlist. And > edata has also an edata_array, what are we going to use evas_array or > edata_array, or do we also need both? Besides that I wouldn't put > ecore_tree into the new lib before it is fixed, it is currently in an > unusable state.
We also have some inthash and we need hash indexed by two int for the font subsytem. And you forgot the simple hash and list implementation of eet :-) Yes, the situation is a bit complex... > As you can see there are many open questions, that needs to be answered > first. That's why raster had the idea to first put the string pool into > the new lib, because - as mentioned before - the API is the same. Of > course we still need to discuss what is going into that lib and how. If > people prefer to discuss it yet and do the whole stuff later at once, we > can do this as well, but just taking edata doesn't work. But why didn't we just put eina inside the libs cvs directory (svn checkout http://efl-research.googlecode.com/svn/trunk/eina eina). And start hacking from here. We can then slowly switch evas , ecore and eet to the data type eina provide or the one we add to eina. It should be easier to start from something with code and hack than agree on what we should put in. But if you are going to do the work, I will agree and help on this project as it's something we need to do. > I hope that clarify things I just don't like edt as a name, but that's really not something important :-) So as long as we have a plan to merge all data type into one lib, I will be happy. -- 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
