On Tue, 1 Jul 2008, Carsten Haitzler (The Rasterman) wrote:
>> I am planning to reorganize the header files of evas, which is a big fat >> mess. Then I remembered a discussion on the ML about data types in evas >> and ecore, and their respective performance. >> >> So I'm wondering if, before reorganising the header files, it would be a >> good idea to extract from Evas.h all the structures and functions related >> to evas data types (array, hash, list and stringshare, but not >> obecjt_list), and put them in Evas_Data.h. I would also put Evas_Bool in >> it as it is needed by some function and as I want to make Evas_Data.h >> stand-alone. > > I don't have a problem with that, as long as Evas.h #include's Evas_Data.h of course. It's in the patch >> I've attached a patch and the Evas_Data.h file >> >> there is no specific library for those evas data types with that patch. >> It's only a move of the api from Evas.h to Evas_Data.h >> >> Some questions, now: >> >> * is it really useful to put stringshare there ? > > yes. its just a datatype like anything else. really a "read-only string > token". ok. >> * should I create a specific lib for data types ? or should the users >> link against evas to use them ? I prefer the first solution. > > well an extra lib isnt a problem, but as long as libevas links to it - does it > really matter? :) it does not really matter yet. But it can be a first step Vincent ------------------------------------------------------------------------- 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
