Hi all, I'm bit busy at the moment and can't discuss much details, but a summary is that I'd really like it to be available as for now.
To clarify few things: - Eina_Value: it's gold, really. No idea why it was mixed into Model discussion. Value purpose is not dependent on Model, although model does use it to exchange properties in a safe way. When designing it I've researched how glib and qt does that, we could do more with optimized handling for arrays. - Eina_Model: although test coverage is not 100%, it does come with much more test than the average code in SVN. ProFUSION is using it for customers code without issue, mostly to abstract data access to DB. All in all I'm satisfied with the API for MODEL (DATA) usage. - during Eina_Model development, I create the Interface concept, with multiple interfaces per type, and interfaces could extend multiple interfaces. But the implementation (internals) assumed for MODEL (data) the common case is not to have multiple INDEPENDENT interfaces to implement the same, thus I implemented the interface lookups in a naive way. THIS is marked in code for future improvements. http://trac.enlightenment.org/e/browser/trunk/eina/src/lib/eina_model.c#L524 Again, this is an internal issue and can be fixed without changing API or ABI. The only synthetic example that exposes this behavior is hard. This is example eina_model_04 in SVN, and the "fix" was to force an unneeded dependency between interfaces. - python, which uses the same object implementation for everything, used a similar naive implementation for almost 10 years before changing it. - the fix for the above problem is suggested in the TODO, it's about changing the algorithm that sorts the dependencies to consider initial ordering as well when pulling the roots of topological sort. - interfaces for models/data is more to help people to override a single part without having to do much work. For example the sole usage of it now is to independently handle properties and children. - aside from interfaces exceptional corner cases, I did not see any other relevant comment to Model; - I don't consider the code to be rushed in, as it's in SVN for more than 2 months. It went through reviews, documentation, examples and is being used in our projects without issues (the found issues were fixed in SVN). - Removing it because it's not in use is chicken-egg. It will not be used if it does not exist. As I said I'm bit busy to code right now, but I would use Eina_Model to implement, at least (no particular order): * SQL loader in esql; * Eet loader and saver; * Eio browser; * Enjoy, allowing plugins to provide backend-independent data (SQL as now, but also FS or network/last.fm). * Elementary to provide views (genlist/grid variants); * Python: to let Python objects be used by C code implementing/using Eina_Model. - I'm bit sad to see that knowing your code is not perfect and flagging it with TODO to help others is seen as a bad thing. I always marked like that, while others just omit those. I don't see why it would make it a blocker for inclusion. Again, this code is intended to map data in a common protocol so we reduce code duplication everywhere. It is based on properties and children. It does events signaling to notify of changes. It does reference counting as multiple views may hold the data. And for these cases I really fail to see how it's broken, badly designed or with flaws. What does seems to happen is a confusion with general objects. This is not general object. Don't expect Evas_Object to be converted to Eina_Model because it has nothing to do. What you should expect is every data provider to talk this API and suddenly you could show a list of something in Elementary without effort. []s -- Gustavo On Mon, Apr 2, 2012 at 4:03 AM, Tom Hacohen <tom.haco...@samsung.com> wrote: > > On 02/04/12 05:39, Carsten Haitzler (The Rasterman) wrote: > > i was hoping/expecting gustavo to appear in this thread and make his > > case. > > > > He's probably unavailable atm. Anyhow, the most important point I raised > is the last one. Given that *nothing* in the efl uses it, why are we > trying to rush it in? -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
